httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: Voting meta-discussion
Date Wed, 20 Nov 1996 16:10:43 GMT
Brian Behlendorf <brian@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

Mime
View raw message