Re: Voting rules/guidelines

[Cliff Skolnick <cl...@organic.com>]

Couple very minor nits.

On Wed, 30 Aug 1995 20:25:20 MDT, Rob Hartill <ha...@ooo.lanl.gov> wrote:

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

I'd actaully prefer to keep the id at the begining.  That way the default
sorting will show new patches at the end.  This may be an issue if you are
using ftp where you can't add options to sort by date/time.

} 
} 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)

YES !

} 
} >   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.

If a second patch is created it should have a new ID. I think you
may be saying this, but I'm not sure, theoretically the text part of
the file anme could change but I hope this is not what you mean.

} 
} 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 clai
  ms)
} >  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 someo
  ne)
} >  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 majorit
  y
} >       decission decides this vote.
} >       (*) quick = about a day... enough time for everyone to read mail and
} >       respond.