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

[Jim Jagielski <ji...@jaguNET.com>]

> On Apr 30, 2018, at 12:26 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> On Thu, Apr 26, 2018 at 1:51 PM, William A Rowe Jr <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> 
>   [  ] The Apache HTTP Server project facilitates the release
>        of bug fixes to the current stable httpd release, correcting
>        defects to previously released code, excluding all new
>        features and enhancements. This is facilitated without
>        inhibiting development of new features and enhancements,
>        including the evolution release of candidates to the public
>        of new features and enhancements under consideration.
> 
> As there are not three PMC members interested in delivering
> bug fix releases to our users, this question fails.

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.

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

[William A Rowe Jr <wr...@rowe-clan.net>]

On Tue, May 1, 2018 at 12:19 PM, Yann Ylavic <yl...@gmail.com> wrote:

> On Tue, May 1, 2018 at 2:08 PM, Nick Kew <ni...@apache.org> 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 http://httpd.apache.org/dev/release.html 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.

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

[Yann Ylavic <yl...@gmail.com>]

On Tue, May 1, 2018 at 2:08 PM, Nick Kew <ni...@apache.org> 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.
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...
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.

>
> I promise to try and contribute
> a positive suggestion!

+1


Regards,
Yann.

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

[Nick Kew <ni...@apache.org>]

> 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.

But the context is complex: an existing process, multiple overlapping
mailinglist discussion threads, multiple candidate ideas.  And I’m not
convinced the proposed clause actually resolves the issues: it may
just leave us with a more complex process.

Sorry if the above is negative.  I promise to try and contribute
a positive suggestion!

— 
Nick Kew