trawick at gmail
Mar 2, 2012, 12:22 PM
Post #4 of 4
On Fri, Mar 2, 2012 at 2:41 PM, Stefan Fritsch <sf [at] sfritsch> wrote:
Re: [RFC] try to solidify feature adoption criteria
[In reply to]
> On Thursday 01 March 2012, Jeff Trawick wrote:
>> On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick <trawick [at] gmail>
>> > 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
> I would prefer rules that distinguish between adding a feature to
> trunk and including a feature in a stable release.
> 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.
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...