From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12938 invoked by alias); 7 Nov 2011 13:35:04 -0000 Received: (qmail 12792 invoked by uid 22791); 7 Nov 2011 13:35:03 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 13:34:23 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7DYMYE027711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 08:34:22 -0500 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA7DYK0P023694; Mon, 7 Nov 2011 08:34:21 -0500 From: Phil Muldoon To: Jason Ekstrand Cc: gdb@sourceware.org Subject: Re: GDB Python API issues References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Mon, 07 Nov 2011 13:35:00 -0000 In-Reply-To: (Jason Ekstrand's message of "Sat, 5 Nov 2011 21:55:17 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00047.txt.bz2 Jason Ekstrand writes: > As I've been working on this project, I've started to find all sorts > of use cases that the API, as it currently stands, doesn't seem to > support. I'm willing to help, but I don't quite know where to start > and I wanted to talk to someone before I start submitting a stream of > bug reports. Go ahead and submit them, but if you work is considerable, or will be large in scope, you might want to discuss it first, before committing hours to coding. If you work on a bug, assign them to yourself first, other people might be working on bugs, including ones that you may file. You might find the CONTRIBUTE guide useful regarding source formatting guidelines, and other submission related issues. This can be found in the gdb source directory. Once you have a patch, you must write a ChangeLog and, depending on the context, a testsuite patch. All new functionality must, imo, have a testsuite patch. If your patch adds or changes functionality, it must include a documentation patch. For new APIs we write a brief entry in the NEWS file, too. gdb/ doc/ and testsuite/ all have their individual ChangeLogs. With the Python API we have a public-facing API promise. We do not allow API changes once it has been released. So anything that was included up to 7.3 has to be API stable. We can change the API on new content since the last release until the next release. If you have to change the behavior of an API, it must be compatible with the old behavior. Typically these scenarios are usually parameter changes in functions. These API differences can normally be worked around with keyword arguments. Also the API restriction applies to what functions or APIs return. These things will normally be picked up in review, but I wanted to note this before you get to work. When you have all the components together, submit it to: gdb-patches@sourceware.org. It should be in a unified diff format. It will be reviewed there. If you do not have FSF copyright assignment papers, you will have to have that processed before you can commit your work. A maintainer will help you get that started after your first patch. Eventually, after a good patch or two, you will be granted "Commit After Approval" status where you can commit your patches after a maintainer has approved them through review. Sometimes, patches can go through a few iterative reviews until you and the maintainer agree on the patch. Some patches require a documentation review, which will involve the documentation maintainer. Others may review your patches, but only a maintainer can approve them. Finally, if you are working from bugzilla, you must include the PR in the ChangeLog. There are lots of examples in the gdb/ChangeLog for this. This triggers a post-commit hook which automatically adds the commit summary to the bug. You must set the target milestone for the expected release of the bug. Right now, that would be 7.4. Hope this helps. I look forward to the patches! Cheers, Phil