Patch Process (Was: Re: [Freeipa-devel] [PATCHES] Fix bug where List parameters were always cloned with keywords parsed from name. + Remove unused reference to old LDAP backend in join plugin. + Make delegation plugin consistent with plugin2 and use new Crud methods. + Fix DS ACI parsing. + Add ACI plugin port to new LDAP backend.)

[Stephen Gallagher]

On 06/02/2009 04:21 PM, Rob Crittenden wrote:
> As a separate issue to the team, we have all been doing multiple patches
> per e-mail lately. I've found this to be difficult to review from time
> to time, particularly when one part of the patch gets nacked but the
> rest are ok (but perhaps related to the nack patch). Do we want to go
> back to 1-patch-per-e-mail?
<snip>

I've been suggesting the following preferred patch process: One "logical
set" per email. The idea is that the set of patches in an email should
comprise a single fix or enhancement. There should only be more than one
patch in an email if the others are direct pre-requisites on the final
patch functioning and are small enough not to warrant their own separate
mailing.

E.g. One patch that adds an extra parameter to a function in order to
support another patch that exposes this functionality to an external API
(like XML-RPC) would be acceptable. On the other hand, having two
patches that each provide a new API complete API implementation is far
too much.

I think a good general rule would be that the email should be based
around the last patch in the set, and it should only include
pre-requisites for that patch, no discrete functionality.

-- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090603/8925e3b7/attachment.p7s>