On Fri, Mar 2, 2012 at 2:41 PM, Stefan Fritsch <[email protected]> wrote: > On Thursday 01 March 2012, Jeff Trawick wrote: >> On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick <[email protected]> > wrote: >> > New features are a natural part of the software life-cycle, but >> > they >> >> One obvious alternative is to simply document that new features of >> any magnitude can be added to trunk at will by any committer. >> Presence in a stable branch is subject to a level of documentation >> considered acceptable to other committers. Merging new features >> to an existing stable branch is subject to commit rules for that >> branch. > > I would prefer rules that distinguish between adding a feature to > trunk and including a feature in a stable release. > > Like: > > Committers may introduce new modules in trunk. > > Anyone can call for a vote to have the module removed, requiring a > passed vote (i.e. three +1s) for removal. > > When a release comes near, anyone who doesn't think the module is > release quality may call a vote. The module needs a passed vote for > inclusion in the release. > > This way a module may mature in trunk. But if it doesn't due to lack > of interest, it would still need people to actively support it in > order for it to be released.
I can't disagree with the role of code maturity, but I'm not sure if that is related to any recent or past conflicts around features. You could consider anything in trunk but not 2.4.x/2.2.x in the same light. The release can't be stable with it there, so it has to be fixed or removed before trunk can become a stable release. To some extent the code maturity question overlaps with other considerations. If the code is not mature AND multiple people are interested enough in supporting that it gets fixed -- belief that it fits in well with httpd, personal reasons to make it work well, whatever -- then all considerations are resolved. Adding modules at-will then requiring someone else to raise a vote and get 3 +1s for removal seems like a very low bar to meet. --/-- todo: 1. get the sense of the project on this 2. write it down 3. limit the scope of future arguments around added features 4. wake up, you were sleeping > >> --/-- >> >> Or just drop the documentation requirement. >> >> --/-- >> >> Not writing down any group think on this invites future conflict. -- Born in Roswell... married an alien...
