Re: GDB Python API issues

[Phil Muldoon <pmuldoon at redhat dot com>]

Jason Ekstrand <jason@jlekstrand.net> 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