httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <hart...@ooo.lanl.gov>
Subject Re: Vote change...
Date Wed, 30 Aug 1995 23:32:44 GMT
> 
> >okay here goes,
> >
> >  1) anyone can say we need a new release, and make a call for patches
> 
> Can we restrict it to one release at a time?  I assume that is
> what you mean, but just checking.

Hadn't thought of multiple votes going on in parallel. Common sense
would stop that I hope.

> +      ScriptAliasKaboom.0.8.11_01
> + 
> +It's useful to have ids (and hence patches) which will stand the 
> +test of time, if only for future reference.
> 
> Yes, that's much better.  However, I would prefer
> 
>        0_8_11_01_a_ScriptAliasKaboom.patch

I think you might like the revised syntax which I guess you've
yet to read.

> with each patch change for the same problem incrementing the "a".
> I believe in reserving .extensions to file typing.

Everything in the patch dir will be a patch, no ?

> What mechanism do we provide for those unable to work on hyperreal?

Everyone can upload to hyperreal as anonymous. They should nag^H^H^Hask
someone to move things from incoming if they don't have an account.
 
> >  3) patches can be changed and/or withdrawn at any time 
> >        withdrawn = just that, the patch is removed
> >          changed = gets a new id and new patch uploaded.
> +
> +Anyone can change *any* patch (multiple versions of the same fix can
> +be compared), but nobody can withdraw someone else's without permission.
> + 
> +Changes to a patch (typically a new patch with the old one withdrawn) should 
> +be clearly documented with comments in the patch header.
> + 
> +Patches should be created using 'diff -C3'
> 
> Perhaps "propose an alternate" would be a better than "change" here.

er, fine.

> Also, 'diff -c file.c.orig file.c' reminds people not to reverse it.

We'd settled in the past on -C3 for good reason, or is your point
here the   ".orig" extension ? if yes, it's worth suggesting that syntax.

> >  4) someone volunteers to collect the votes, another or same person 
> >        volunteers to build the new version. The vote collector and
> >        version builder agree on a voting deadline.
> 
> I'd recommend that this always be two people, given the "shoot the messenger"
> syndrome.  Since we are within strangling distance of each other,
> I'd like to volunteer to conduct the next distribution vote, with rst
> continuing as the version builder.

you can recommend it, but lets not make it strict. When I did some of the
earlier builds, I think I would have been slowed down waiting for the
"judges decision". But 2 people is fine, if 2 volunteers are willing.

> >  6) the vote deadline can be voted on too.
> 
> No.  That allows the entire voting process to be delayed indefinitely
> by a single veto.  

Mmm, I was thinking more along the lines of having the first deadline
stay as the default and having other deadlines (extended presumably)
put forward... these can be blasted away with a single veto, but if enough
people want an extension, there'll be a procedure to handle it and we
won't have to flame each other over timing.

> The vote deadline should be two days after the
> vote is called.  

do we need to restric the votes to the end of the process ? if we
allow votes (and the comments that go with them) to flow over the
whole announce->build period, then more issues can be raised before
the last minute rush.

> The vote should be called no more than 10 days,
> and no less than 4 days, after the call for patches.

now where getting technical :-)

I'm willing to give that a try, but a feel it might get restrictive.
Does it even apply if votes are accepted at all times ?

> However, we do need an express vote for security hole patches,
> just in case the need arises.  I think such a patch can be voted on as
> a singularity and released to CERT within 24 hours.

good point, but hopefully so uncommon that we'll all forget what the
procedure for handling it is. I suppose 1 working day should 
give everyone in all timezones a chance to read their mail.
 
> >  7) the release is assumed to be public unless vetoed.
> 
> Our public is our test base.  I'd say that the release is assumed to
> be a beta unless the vote itself is on changing an existing beta to
> the official release (in which case patches are not allowed).

Are you saying that all versions should be released to the public
and just named accordingly. When we get to feature patches, it might
be useful to save up a series of features. Having the version number
increment on a weekly basis might put a strain on webmasters who get
pestered by users to upgrade in order to use the latest bells and whistles. 

> >  8) no veto can be overruled, they can only be withdrawn.
> 
> That will guarantee deadlock if someone vetoes one patch which is
> a prerequisite for others (it has happened in the past).  Given that
> we are now a large group, I'd recommend that we come up with a better
> means of resolving vetoes, or at least strict guidelines on justification.

that's something I meant to add earlier. A veto without a defendable
reason should be void.

So if I veto something and fail to offer a defence (should someone argue)
then that veto can be declared void. You can veto again later, but be
prepared to be flamed alive if you're just being stuborn.

> >  9) the definition of a positive (aka +1) vote is that you've
> >      a) looked at the patch (to see what it's about)
> >      b) patched the file into the appropriate version
> >      c) compiled the patched source
> >      d) observed no side-effects  (not necessarily tested the patch's claims)
> 
> Er, no "bad" side-effects -- many good patches reveal other, unrelated
> or lesser bugs. 

good point.

> > 12) the version builder can correct mistakes made during the build
> >      e.g. removing a patch that wasn't supposed to be in or adding
> >      one that was missed.
> 
> That is the same as "a new version is built with the approved patches."

12) makes it explicit that the builder doesn't have to ask permission
or call for votes if (s)he accidentally screwed up.

> > 14) if a new patch causes any problems a quick vote (*) should be taken on
> >      whether to remove, replace or leave the patch as it stands. A majority
> >      decission decides this vote.
> >      (*) quick = about a day... enough time for everyone to read mail and
> >      respond.
> 
> I'll veto this last one -- no re-votes unless the new version does
> not work the same as requested by patch vote.

I didn't follow that. Having reread 14), it should perhaps be reworded..

if after a build, one of the patches is found to cause a problem a majority
quick vote shall determine whether the patch is left/replaced/removed

does that help ?

>  A single veto (limited
> to these exact conditions) should stop a public release until the
> build error is fixed and re-checked.

maybe we're talking about different things, I'm thinking of a case,
e.g. that old pain in the ass unmunge_name problem, where a problem
is discovered after a build. In this case the patch had to be removed
'cos it caused more problems that it tried to fix. If we had to try
to "fix" the problem, we might have been there for weeks.


I'll archive all these comments and HTML'ize the outcome for final
approval.

rob

Mime
View raw message