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]