Mailing List Archive

[RFC] try to solidify feature adoption criteria
New features are a natural part of the software life-cycle, but they
bring with it a greater product surface area to document and support,
as well as more technical issues which could detract from other
developer activities. For this reason, the httpd project as a whole
has a vested interest in avoiding the inclusion of features which
don't have adequate developer interest. This is especially true of
the core Apache HTTP Server distribution, but extends also to
sub-projects. Without adequate developer interest and oversight, the
project cannot distribute and support the feature. Thus, features of
a significant nature must be formally accepted.

Judging whether or not a feature is significant is inherently
subjective, but for the purposes of efficient consideration the
following criteria have been established. Any of the following is a
new feature which must be formally accepted:

* any new plugin module, aside from those created as a result of
refactoring existing code in the server
* any new separately executable programs intended for end users

Acceptance of new features is generally a non-technical issue subject
to voting similar to that a release: at least three project members
must vote affirmatively for the feature, and there must be more
positive than negative votes for the feature. Acceptance can be
considered for inclusion in the core server distribution, an existing
sub-project, or a new sub-project. Note: Moving an existing feature
from a sub-project to the core server distribution is also subject to
formal acceptance.

A feature may also have technical concerns which must be addressed and
are subject to a veto; vetoed technical issues must be resolved before
inclusion, even if inclusion of the feature has been accepted. The
decision to implement a feature as a new module or part of the core or
existing modules is also a technical consideration. As such, a veto
against including tangential features in the core server or existing
modules could result in approval being required by virtue of the
requirement to implement the feature as a separate module.

Acceptance of new features is separate from any necessary IP clearance.
Re: [RFC] try to solidify feature adoption criteria [ In reply to ]
On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick <trawick@gmail.com> 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.

--/--

Or just drop the documentation requirement.

--/--

Not writing down any group think on this invites future conflict.
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@gmail.com>
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.

> --/--
>
> Or just drop the documentation requirement.
>
> --/--
>
> Not writing down any group think on this invites future conflict.
Re: [RFC] try to solidify feature adoption criteria [ In reply to ]
On Fri, Mar 2, 2012 at 2:41 PM, Stefan Fritsch <sf@sfritsch.de> wrote:
> On Thursday 01 March 2012, Jeff Trawick wrote:
>> On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick <trawick@gmail.com>
> 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...