Theo Van Dinter <[EMAIL PROTECTED]> writes: > -1
I think sometimes we are a bit cavalier throwing around -1. There is a floating point scale here. ;-) My goal is to figure out and document these corner cases before we find ourselves stressed out and fighting in the middle of a release. Frankly, the last release was a bit too stressful over some of these issues where we've gone either way in the past. > The current documentation contradicts itself in several places. > For instance: > > "Note that no one may veto a release. The PMC or the release manager > may revoke all votes on a release if a new major problem is discovered > prior to publication of a release and request a revote. However, once > there are greater than 3 positive votes, the release may be made at > any time. In addition, the RM may decide against making a release even > if the required votes have been made." 1. Revoking votes is simply calling for a new vote since some major issue has come up that people did not know about prior to their vote. > 1) It says that no one may veto a release, and then it goes on to say > that the RM may veto a release. If no one can veto, then no one can veto. > 2. As far as the RM deciding against making a release, I should clarify that the RM can only decide to do that prior to the point of publishing tarballs. It's on the RM's head, so I think it's fair for the RM to chicken out. (If it happens for silly reasons or in an annoying way, then it's likely the RM won't get too many votes next time.) > 2) "... once there are greater than 3 positive votes ..." So that's 4 > votes for a release. I'm fine with that, but everywhere else it says > 3. Typo. Agreed. > "If the "point of no return" described in the build/README has not been > reached, then the release may be abandoned and begun again." > > 3) There is no easily identifiable "point of no return" in build/README. > Is it the release prep commit, the tree tag, the tarball build, the > "x.y.z released" commit? I'd say if we go with the "version burned" approa= > ch, > it's the tree tag stage. Whichever it is, we should make it an easily > identifiable stage, such as using the phrase "point of no return". ;) This should be pretty clear in the document now. :-) > I still think there needs to be some general time given so that the people > involved know about a release before it happens. We look very foolish > as a whole when, say, a PMC member is discussing future releases with > third parties, and then it's pointed out by said party that a release > just occured which was not known about ahead of time. How about this? The intention to make a release should be announced 48 hours before tarballs are ultimately published (unless it is a security fix). The testing period after tarballs have been created and before tarballs are made public should last at least 12 hours, but that period of time is up to the RM. > Should there be any discussion about stable vs development releases and > generally what is expected? There could be a bit more, sure. > I'm not hot on the "version number is burned at tarball time" idea (pun > intended?) It really does tend to confuse users who wonder why things go X, > X+1, X+3, ... This isn't a major issue, but I wanted to share. It's now burned when tarballs are *published* which is not too confusing. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
