[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VOTE] Allow for defect fix releases at httpd

On Tue, May 1, 2018 at 12:19 PM, Yann Ylavic <> wrote:
On Tue, May 1, 2018 at 2:08 PM, Nick Kew <niq@xxxxxxxxxx> wrote:
>> That's not quite fair.
>> For me, to be honest, I couldn't quite understand the question at
>> all... I had a real hard time parsing it. It looked like, by voting +1,
>> I would also be agreeing to other things (like disallowing
>> any new features or enhancements to any release) which
>> would be unacceptable.
> +1.  I’d be uneasy about that clause without a much more in-depth
> review of its context, which isn’t going to work as a mailinglist
> discussion (too confusing; TL;DR).
> At the same time, I applaud what Bill is trying to do.  We have a
> problem, we discuss it, the discussion goes nowhere, Bill makes
> a valiant effort to take it somewhere.

+1, I'd first like to thank Bill for trying to reach a consensus on
our release numbering/policy.

For anyone who wants to work to change this (I'm out), I'll take this
apart so someone else can better wordsmith;

 1. The Apache HTTP Server project facilitates our committers
     collecting bug fixes to the current stable httpd version for
     a release, distinct from new features and enhancements.

 2.  Nothing in 1. above may inhibit committers from developing
      of additional features and enhancements, and delivering
      releases of those features and enhancements.
In other words, any bug fix tending and releases must coexist with
new feature development/enhancement releases. That's what it said,
and I should have said it more plainly. The follow up question is how
do these coexist?
In the same time, I'm not sure three PMC members wanting a
bug/security fixes only branch can prevent three others to backport
improvement/feature there...

Anyone championing some change to the release process should
note and perhaps express
the change to address the following paragraph;

Who is in charge of a release?
The release is coordinated by a Release Manager (hereafter, abbreviated as RM). Since this job requires trust, coordination of the development community, and access to subversion, only committers to the project can be RM. However, there is no set RM, and more than one RM can be active at a time. Any committer may create a release candidate, provided that it is based on a releasable (non-vetoed) tag of our current subversion repository corresponding to the target version number. In order to facilitate communication, it is deemed nice to alert the community to your planned release schedule before creating the release candidate, since some other folks may be on the verge of committing an important change (or backing out an error). A release candidate should only be made when there is an intention to propose it for a vote on public release. There are no "private" releases at Apache.

This dates from the founding of the project; at one time there were
simply a collection of patches, which an RM assembled. So two
individuals doing so at the same time to their own design wasn't
impossible. Any PMC member can veto a change.

At present there is no mechanism other than asking/vetoing
proposed changes to defer them from one release to the next,
effectively ignoring suggestion 2. above.

Cherry picking is very troublesome in svn, and not realistic using
the present numbering schema/existing svn branch mechanics.
It is trivial in git.

In terms of introducing an enhancement/feature into what the
project declares to be a maintenance/bugfix-only branch, should
be so extraordinary that a proposal to dev@ is mandatory to ask
for such an exception. If the project changes mechanics to make
both 1. and 2. above possible, then there would be little incentive,
since the new development branch would be up for a release of
its own, real soon now.

So I'd like to ear Bill's further suggestions to "find mechanisms to
accomplish this goal" which we could all agree/amend on, and move
forward for the community benefits!

Bill, withdrawing from the discussion shouldn't be the next step I
think, please describe the whole picture as you see it (again? sorry
if that happened already in the many/too much threads on the subject,
at least I couldn't have that big picture yet).
There is certainly a way to have both a conservative release (not
exactly cast in stone either, to which extent?) and another or more
ones with less API/ABI garantees (which grow faster and attract devs,
maintained until?).

It seems that the status quo is not what all of us/the community want, either.

There have been a number of proposals, and I'm happy to hear others,
which bring us back to the ability of an RM cutting to the chase of getting
a bug fix release out the door with minimal hassle. Migrating to more of
a semver scheme, perhaps extending the life of version majors, etc,
could all be useful. 

I'm done playing word games and fetch me a rock for certain critics,
so I'll leave it to anyone else who cares to advance the dialog. As I had
hinted, that suggested vote was not the last question for the group to
ask itself. Perhaps a change of champions will advance the discussion,
but without support that both 1. and 2. above can and must coexist,
the sand underneath us is too loose for the committee to find its footing.