Re: Voting meta-discussion

[Brian Behlendorf <br...@organic.com>]

On 18 Nov 1996, Paul Richards wrote:

> Paul Sutton <pa...@ukweb.com> writes:
> 
> >   3.  It is wrong to develop code on the principle of first
> >       putting it into the current code then taking it out if it fails.
> >       New code and features should be discussed first and tested before
> >       being applied after an approval vote
> 
> I disagree with this. You're advocating that cvs be used to combine
> code after it has been tested, this is going back to the patch-n-vote
> days where we'd have to apply patches on our own boxes to test them
> out before they go into cvs. This is very difficult to do, it was then
> and it would be more so now, with more frequent contributions.
> 
> None of the strong advocates of voting have yet shown why the current
> development practices are failing? Is Apache any less stable? My view
> is that a hell of a lot more progress has been made since we started
> using cvs than when we had to patch-n-vote.

Subtle difference: when we had patch-n-vote, the voting process occurred in
batches, which meant that not only did everyone have to apply them by hand,
they had to test them all at once at each batch time to know whether they
worked or not.  And then after the vote someone had the thankless task of
trying to cobble all the patches together and make them happy, even if they
conflicted majorly (sorta like our California state propositions elections
recently - conflicting propositions are routinely both approved :)  Now with
CVS, someone can propose a patch against a current CVS tree, we all go test it,
and within a matter of days (hours, at times) the patch can be integrated with
the code.  This is much better, and has accelerated development, at least
development of the "quick fix" variety, without compromising the
let's-carefully-consider-this situation.

I like being able to point random folks to http://dev.apache.org/from-cvs/ and
know that what they pull down will have some modicum of stability.  I also know
that we as a team are event driven, and if experimental code is put in a
code tree and no one has the time or inclination to look at it, the default
action at that point is that it becomes part of the release.  

Hmm, I know I'm not making myself clear.  Maybe it could be phrased as, "Would
you, the chef, rather put red hot chile peppers in the wedding cake and await
feedback, or would you ask first?" 

> >   4.  A feature freeze does not imply a free-for-all to commit their
> >       favourite patches just prior to the freeze
> 
> This was hardly a free for all. The desire for a satisfy patch has
> been there all along and all I did was take item no 1 off Rob's todo
> list and actually do it.

I think this event boiled down to a basic misunderstanding.  All is
forgiven, let's move forward.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS

Re: Voting meta-discussion

[Paul Richards <p....@elsevier.co.uk>]

Brian Behlendorf <br...@organic.com> writes:

> Subtle difference: when we had patch-n-vote, the voting process occurred in
> batches, which meant that not only did everyone have to apply them by hand,
> they had to test them all at once at each batch time to know whether they
> worked or not.  And then after the vote someone had the thankless task of
> trying to cobble all the patches together and make them happy, even if they
> conflicted majorly (sorta like our California state propositions elections
> recently - conflicting propositions are routinely both approved :)  Now with
> CVS, someone can propose a patch against a current CVS tree, we all go test it,
> and within a matter of days (hours, at times) the patch can be integrated with
> the code.  This is much better, and has accelerated development, at least
> development of the "quick fix" variety, without compromising the
> let's-carefully-consider-this situation.

You're assuming the cvs tree is static while this peer review takes
place. This is never the case, if it was the patch mechanism would
have worked OK since we'd have just applied the patches sequentially.

This is how I think a voting model would have to work:

1) There's a queue of changes, if you don't deal with changes
   sequentially then you can't keep local copies of the src in a sane
   state. Otherwise, more than one person can submit a patch against
   current at the same time. You have to commit one change before the
   next change can actually be submitted as a patch.
2) We all grab the next patch and apply it to our local copy. We run
   the server with that change and vote.
3) If the patch fails it gets removed from the queue and if
   resubmitted would go on the end.
4) If the patch passes then it gets submitted to cvs.
5) We'd have to reverse the patch in our local copies of the tree and
   then do a cvs update to get it back again.

Now, for this to have a reasonable turnaround time the peer review
would have to be either a simple read through of the code or a limited
test of a few hours. Hardly worth it really.

If some days or weeks later the change transpires to be bogus it's
removal would have to be queued as a change and if there are
subsequent dependancies on it the whole process unravels.

Your opinion of the turnaround time is optimistic given timezone
differences. This is significant if anyone is allowed to veto a change
before it is committed in which case you have to wait a day or so for
everyone in the project to have a change to peer review it. I've
*VERY* against the idea that individuals can veto things anyway. Apart
from a deadlock (like we playfully had with the docs) why should a
single individual block something that other people are in favour of?

Once you go back to voting you go back to all the problems of the
patch system since you effectively *are* dealing with patches and cvs
is just a storage and distribution mechanism.

If you add to the equation the likely fact that your src tree isn't
going to be a carbon copy of the repository but a work-in-progress
tree then perhaps you can start to see the problem? You'll have to
apply the patches by hand to start with, you can't make too many local
changes with the patch installed otherwise you won't be able to
reverse it. You could have two copies one clean and one you're working
on but then you can't test whether other people's changes work or
break your work in progress etc etc.

I fail to see why this is necessary. 

1) People aren't granted cvs access unless they show themselves to be
   competent so they should not be committing changes they haven't
   tested themselves.
2) Most changes are not contraversial and requiring a vote would
   definately slow down progress considerably.
3) Peer review should definately take place but it should take the
   form of either
   a) having someone else take a look at your code before commiting it
   b) people constantly following the commit messages and testing the server
   c) both.

Note that I'm not advocating a free-for-all scenario, I'm in favour of
peer review but not some required voting scheme. For a start, who's to
say whether the required 3 people are all qualified to make decisions
about all aspects of the code? I've no idea how the proxying stuff
works, I'm never likely to pay any attention to changes made to it so
I'm never going to vote on it. I will however notice if a recent proxy
commit suddenly breaks something. Umm, what I'm getting at here is not
whether any 3 people are qualified but rather, will there be 3
qualified people in the first place or do we reach the stage where if
there aren't the required number people jsut vote +1 to get some
progress. I've seen this happen many times already.

If there are any problems with 1.2 then it's due to a lack of explicit
coding rules rather than a lack of vetting. Looking over the code over
the last two days it really is a mess but it's mostly a mess because
of a total lack of a coding policy and an overall project plan.

A pre-commit peer review is not going to improve the structure of the
code without some concensus. We tried to sort out these problems but
the issues got sidelined.
 
> I like being able to point random folks to http://dev.apache.org/from-cvs/ and
> know that what they pull down will have some modicum of stability.  I also know
> that we as a team are event driven, and if experimental code is put in a
> code tree and no one has the time or inclination to look at it, the default
> action at that point is that it becomes part of the release.  

You shouldn't put experimental code into the tree, you should only put
code in that you've tested on your own box. As long as it doesn't
break the server then I don't see why this is a problem. Totally
experimental development should get approved here first, for such
things I would accept that a voting procedure is necessary.

I agree that /from-cvs should always be an usable server, we have the
same rules for -current in FreeBSD, it is a *very* rare event that
-current is actually unusable or severely unsafe.

> Hmm, I know I'm not making myself clear.  Maybe it could be phrased as, "Would
> you, the chef, rather put red hot chile peppers in the wedding cake and await
> feedback, or would you ask first?" 

To use the same analogy: You have to have basic chef skills before
being allowed to enter the kitchen. Putting chile's into a wedding cake
as an experiment would get yourself barred from my kitchen.

-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155