gnustep-dev
[Top][All Lists]
Advanced

[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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]