PatchSubmissionGuidelines

Date: Wed, 23 Jan 2008 12:25:20 -0800
From: Eric Blossom <eb@comsec.com>
Subject: Re: [Discuss-gnuradio] Enhancing Gnuradio Doxygen Generated Official Documentation
To: "Firas A." <firasmail2000@yahoo.com>
Cc: Discuss-gnuradio@gnu.org
Sender: discuss-gnuradio-bounces+eb=comsec.com@gnu.org

On Wed, Jan 23, 2008 at 11:42:50AM -0800, Firas A. wrote:
>
> Hi Eric,
>
> kindly, I have a question about the possibility to make the
> documentation changes to svn source files.
>

Firas (and everybody else!),

I'd prefer that you send us lots of relatively small changes, instead
of one big change in 15 days.  This allows one of the committers to
take a quick look at the patch and apply it.  Smaller patches take
less review from us, and are more likely to get applied right away.
This is the way we manage the software too.

Here's how to do it:

** check out the trunk
** edit the header file documentation or python doc strings, or whatever
** when you're happy with your changes send the output of

    $ svn diff

  to patch-gnuradio.

One of the committers will review the patch and if it looks good will
apply it to the trunk or will suggest changes.

Then you can update your copy of the trunk, and continue working.  To
pipeline this process, checkout a new copy of the trunk in a different
directory and start working on your second set of changes in there.
Then when you send the diff, it'll be for the new changes only.

After we've seen a series of good patches from you that apply cleanly,
and follow our conventions, we can talk about getting you write
access to the repo.

Thanks again for your commitment to improving GNU Radio!

Eric

Date: Wed, 23 Jan 2008 13:02:11 -0800
From: Johnathan Corgan <jcorgan@corganenterprises.com>
Subject: [Discuss-gnuradio] Patch submission guidelines
To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Sender: discuss-gnuradio-bounces+eb=comsec.com@gnu.org

None of the below are mandatory, but are some conventions to follow to
help us more easily evaluate and apply a patch.  These are not just
for documentation patches, but for functionality as well:

* Patches are submitted in the form of a SVN created diff, not individual files.

* Diffs are made from the GNU Radio tree root, and are based on an SVN
check out of the GNU Radio trunk.

* The diff contains the minimal but related incremental changes, for
all the files needing modification to implement the change.  In other
words, the diff should take a working GNU Radio source tree and modify
it to become a working GNU Radio source tree with the feature
implemented.

* After applying the diff, the tests 'make check' and 'make distcheck'
must both pass.

* When relevant, QA code exists to automate unit testing of the new
functionality.

* There should be no additional compiler warnings to what already occurs.

* No gratuitous whitespace changes.

It does take time and practice to follow the above, so again, the
above aren't rules, but more of a "scoring system" that will improve
the chance of your contribution being accepted into the project.

Incidentally, these are the same criteria that we review before we
merge code from our developer branches into the trunk.





注：PatchSubmissionGuidelines（原文出处，翻译整理仅供参考!）