[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting reviews and submitting patches
From: |
Richard Frith-Macdonald |
Subject: |
Re: Getting reviews and submitting patches |
Date: |
Sun, 14 Jun 2009 18:56:40 +0100 |
On 14 Jun 2009, at 17:20, Dave MacLachlan wrote:
Sorry for the newbie question, but I want to make sure I get it
right ;-)
I've got a couple of patches that I'd like to submit to gnustep-
base. Google has signed off on having them submitted to the project,
so the legal steps are taken care of already.
Including copyright assignment to the FSF? That's a requirement for
anything substantial.
a) Is there a coding standard for gnustep somewhere that I missed?
Right now I'm guessing no.
If you don't know, then yes, you missed them.
The coding standards are the GNU coding standards, but with some
modifications for Objective-C (since the GNU ones are basically for
C)...
http://www.gnustep.org/resources/documentation/Developer/CodingStandards/coding-standards.pdf
We try to keep coding style fairly rigorously consistent in GNUstep
(certainly in GNUstep proper ... the core libraries) as an aid to
general readability/maintainability, but a lot of the associated
projects and non-code packages are left pretty much as the person who
originally wrote them happened to do things.
b) How do people normally handle reviews?
We have a project page at https://savannah.gnu.org/projects/gnustep/
where tracking of bug reports and patches is done.
One a patch or bug report is added there, there's a good chance that
core developers will look at it :-)
There aren't many of us though, so a follow-up to the developer or
discussion mailing list is good if nobody has commented within a few
days.
c) Anything else I should know before diving into the world of
submitting patches?
General principles ... try to keep patches small so that they can be
reviewed easily/quickly, and so that changes can be done/tested in
stages with each patch leaving the main code working. Implementation
of new classes is simpler ... because that's normally highly localised
and unlikely to break anything.
Ideally, present testcases. The gnustep testsuite is available from
subversion at http://svn.gna.org/viewcvs/gnustep/tests/testsuite/trunk/
It's really simple to produce testcases to fit into this testsuite,
and they give you a way of demonstrating that what your code is
supposed to do (and verifying that it works the same way on MacOS-X as
on GNUstep, since the testsuite can largely be run under MacOS-X).