TODO list proposal for volunteers

[Gerald Carter]

David Lee wrote:
> 
> > For those without CVS write access (non-team members),
> > patches should be incremental and in the form of
> > context diffs.
> 
> Is that right?  Nice in theory, but in practice...?
> 
> I assembled a post-2.0.7 patch for utmp back in May.  This 
> was made against a production 2.0.7 baseline.
> 
> But I had a note from Jeremy saying he just tried to put 
> it into 2_2, and that it doesn't work, and could I re-do it 
> etc. etc.
> 
> Yes, I'm very willing to try to cooperate.  But surely 
> the "team"  (those> maintaining the CVS tree) should try 
> to ensure that a patch against the most recent production 
> version should be valid.

This is a tough issue.  As code develops, things change.
We all know this I realize.  Part of the difficulty in
software development is ensuring that bugs that were fixed
in previous releases don't creep back in due to unapplied
patches to the main source tree.  

I don't have a good answer.  Obviously someone who 
wrote the patch can "upgrade" it to work with the latest
source tree quicker than someone else can fgure it out.
This type of development results in various people "owning"
parts of the code.  The problem with a widely distributed
model like this is that things can fall on the floor if
everyone is not in the loop.

The alternative is for patches to be filtered through a core
team of developers.  This of course solves, the previous 
problem but does keep core developers away from active 
development a lot as the number of small patches increases.

So for now, we have to settle with two forms of patches.
Those against HEAD (or SAMBA_2_2) and those against current
production releases (e.g. 2.0.7).  I don't see any way around
this but am willing to learn :-)

One possibility is to encourage more in depth descriptions
of submitted patches so that they can be judged on the spirit
in which they were written.  This might be able to help
determine their validity against the current CVS source 
tree(s).  A joint effort between the patch author and a team
member may be necessary.  It is hoped that someone who goes 
to the effort of fixing a bug (or adding a feature) will
also be willing to ensure that this code gets into future
releases so that he or she will not have to continual repatch
a local source base.  Everyone benefits.


> (I've tried checking this twice with Jeremy, 
> but no answer...)

I'll bug him some today. :-)

> Two questions:
> 
> 1. (Principle) Have I misunderstood the principle?  
> Could a team member confirm that patches against the 
> most recent production version are acceptable?

See above comments.

> 2. (For my umtp patch)  Could a team member indicate 
> whether 2_2 was branched off before 2.0.7 was 
> finally released?  I can easily supply the patch if 
> you wish to try to apply it (and/or to demonstrate that
> the problem lies at my end).

HEAD was branched during the beta release of 2.0.0.  
Thus changes applied between 2.0.0 and 2.0.7 should have been
applied to HEAD as well, but may have been forgotten.

SAMBA_2_2 was branched from HEAD on Sept 19, 2000.

> If someone's patch fails to apply to the current 
> production release then there is a reasonable 
> expectation for them to fix their patch.  But if it
> does apply cleanly, who is responsible for reconciling 
> it with the emerging next release?

We're hoping that the author of the patch will (what if 
I said please?) :-)






Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com  VA Linux Systems    gcarter at valinux.com
       http://www.samba.org       SAMBA Team           jerry at samba.org
       http://www.eng.auburn.edu/~cartegw

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )