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: Voting rules/guidelines
Date Wed, 30 Aug 1995 20:25:20 GMT

I'll start refining this proposal..
 
>   1) anyone can say we need a new release, and make a call for patches
>   2) patches are uploaded to hyperreal with a unique id (number). The
>       number is fixed at time of uploading, and should be 1 more than
>       the highest existing patch id. 
>       Start at number XYZ01     for patches to release X.Y.Z,  e.g
>                       081101    for patch 1 to release 0.8.11

instead of the above as a filename convention, I think it better to
have the id as an extension, e.g

      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.

Patches should contain a couple of lines of description that can be used
at build time to document the change in the changelog (CHANGES file)

>   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'

>   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.
>   5) everyone can vote and comment as much as they want.
>   6) the vote deadline can be voted on too.
>   7) the release is assumed to be public unless vetoed.
>   8) no veto can be overruled, they can only be withdrawn.
>   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)
>  10) late votes..
>       positive votes: can be ignored or accepted at the discretion of the
>         person building the new version.
>       vetoes: ignored unless someone who voted positively publically
>         switches to a veto  (i.e. if you're late you have to convince someone)
>  11) a new version is built.
>         patches applied
>         version number incremented
>         changelog updated
>  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.
>  13) everyone is encouraged to download the new version and try it for
>       at least a day if the version is to be publically released.
>  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 HTML'ize these guidelines or whatever becomes of them at some point.


rob

Mime
View raw message