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

[Stefan Eissing]

> Am 17.05.2018 um 15:13 schrieb Eric Covener :
> 
> I tried to collect some bullets here:
> https://wiki.apache.org/httpd/ReleaseStrategyProposal
> 
> If anyone else has priorities/problems/proposals/refinements please have a 
> look.

Thanks for putting in the effort. 

With the mail storm some days ago, I did not get a feeling that we have 
some sort of common ground on how to go forward. The opinions seem to vary
quite a bit, to put it conservatively.

From my personal point of view (which is mine, but not necessarily the correct
one for the project), bringing in new functions like http2 or Let's Encrypt
requires a lot of patience. And, due to the lousy test coverage, you can never
be sure not to have destroyed someone's previous use case. So, any boldness -
without which there would be no progress - gets easily penalized (see the 
mod_md vs. mod_ssl breakage).

I am amazed, not surprised, but still have this sense of awe and wonder when
I see how many show up when it comes to discussing processes and restrictions
for the few people who actually do still write code or documentation. This
I find funny - in my good moments.

Anyways, I am in maintenance mode these days. What could motivate
me again for trying new things - just to make clear where I stand - is:

- monthly, non-2.4 releases with CTR policy, with API breakage more
  likely than not each month. Preferably starting with a 2.4.x copy,
  ditching trunk.
- join 2-3 people who *do* a restart of our test cases. I would contribute
  adapted mod_http2 and mod_md test suites into that.

My €0.02.

Cheers,

Stefan

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

[Eric Covener]

I tried to collect some bullets here:
https://wiki.apache.org/httpd/ReleaseStrategyProposal

If anyone else has priorities/problems/proposals/refinements please have a look.

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

[Micha Lenk]

On Wed, May 02, 2018 at 02:56:03PM -0400, Jim Jagielski wrote:
> On May 2, 2018, at 10:45 AM, Micha Lenk  wrote:
> > On 05/01/2018 04:33 PM, Graham Leggett wrote:
> >> What has been missing is input from the major distributors of our
> >> software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from
> >> Scratch, etc), who I believe are probably going “httpd is a mature
> >> project, we have nothing to worry about”. I would recommend against
> >> making changes to our approach without soliciting the views of these
> >> people and making sure they’re all catered for.
> > Why would you make a proposed change dependent on the (almost
> > necessarily contradicting) views of external entities? Is the
> > feedback from the major distributors through existing channels
> > really so bad that the httpd project can't get to an opinion of what
> > it would like to accomplish on its own? What exactly are you afraid
> > of?
> 
> Due to the modular aspect of httpd, we are lucky to have an extremely large,
> vibrant and diverse eco-system of module authors. Some are companies
> that provide functionality via binary modules, others are single-author
> GitHub authors.
> 
> A change on versioning and what versioning means and guarantees
> related to versioning affects this extremely large community. There is
> also the ISV and commercial *providers* of httpd to be considered as
> well, and how these changes would affect them.
> 
> With all that in mind, you can't just "willy-nilly" decide to change
> things without knowledge of how such changes will affect the eco-
> system as well as without a really solid rationale for said change.
> I don't consider "I can point out a handful of projects that do it
> different than httpd" as a solid rationale.

Yet I fail to see how this could be seen as an argument not to agree on
something like trying to provide bugfix only releases.  The vote was
about /what/ to accomplish, not even /how/ (i.e. versioning was not even
mentioned in the vote).  Am I missing something?

Regards,
Micha

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

[Nick Kew]

> On 2 May 2018, at 15:45, Micha Lenk  wrote:
> 
> Hi Graham,
> 
> On 05/01/2018 04:33 PM, Graham Leggett wrote:
>> What has been missing is input from the major distributors of our
>> software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from
>> Scratch, etc), who I believe are probably going “httpd is a mature
>> project, we have nothing to worry about”. I would recommend against
>> making changes to our approach without soliciting the views of these
>> people and making sure they’re all catered for.
> Why would you make a proposed change dependent on the (almost necessarily 
> contradicting) views of external entities? Is the feedback from the major 
> distributors through existing channels really so bad that the httpd project 
> can't get to an opinion of what it would like to accomplish on its own? What 
> exactly are you afraid of?

+1 to Jim’s reply to that (insofar as it addresses your point).

I’d also add: this mailinglist is open to our downstream packagers.  Some of 
them
contribute actively, and one would hope they all at least keep an eye on this 
list
and would speak up if a proposal seemed likely to cause them real difficulties.
So open discussion here *should* provide a reasonable level of engagement
with our distributors.

— 
Nick Kew

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

[Jim Jagielski]

> On May 2, 2018, at 10:45 AM, Micha Lenk  wrote:
> 
> Hi Graham,
> 
> On 05/01/2018 04:33 PM, Graham Leggett wrote:
>> What has been missing is input from the major distributors of our
>> software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from
>> Scratch, etc), who I believe are probably going “httpd is a mature
>> project, we have nothing to worry about”. I would recommend against
>> making changes to our approach without soliciting the views of these
>> people and making sure they’re all catered for.
> Why would you make a proposed change dependent on the (almost necessarily 
> contradicting) views of external entities? Is the feedback from the major 
> distributors through existing channels really so bad that the httpd project 
> can't get to an opinion of what it would like to accomplish on its own? What 
> exactly are you afraid of?
> 

Due to the modular aspect of httpd, we are lucky to have an extremely large,
vibrant and diverse eco-system of module authors. Some are companies
that provide functionality via binary modules, others are single-author
GitHub authors.

A change on versioning and what versioning means and guarantees
related to versioning affects this extremely large community. There is
also the ISV and commercial *providers* of httpd to be considered as
well, and how these changes would affect them.

With all that in mind, you can't just "willy-nilly" decide to change
things without knowledge of how such changes will affect the eco-
system as well as without a really solid rationale for said change.
I don't consider "I can point out a handful of projects that do it
different than httpd" as a solid rationale.

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

[Micha Lenk]

Hi Graham,

On 05/01/2018 04:33 PM, Graham Leggett wrote:

What has been missing is input from the major distributors of our
software (Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from
Scratch, etc), who I believe are probably going “httpd is a mature
project, we have nothing to worry about”. I would recommend against
making changes to our approach without soliciting the views of these
people and making sure they’re all catered for.
Why would you make a proposed change dependent on the (almost 
necessarily contradicting) views of external entities? Is the feedback 
from the major distributors through existing channels really so bad that 
the httpd project can't get to an opinion of what it would like to 
accomplish on its own? What exactly are you afraid of?


Regards,
Micha

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

[William A Rowe Jr]

On Tue, May 1, 2018 at 12:19 PM, Yann Ylavic  wrote:

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

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

[Yann Ylavic]

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

[Graham Leggett]

On 26 Apr 2018, at 8:51 PM, William A Rowe Jr  wrote:

> With discussion exchanged (across several years), and various
> arguments presented, we should be able to adopt or reject the 
> first of several possible questions as a PMC. This is the meta-
> question, any versioning discussion is irrelevant without specific
> purpose or goal, and follow on questions would decide how the
> PMC decides to solve this purpose;

In order to decide on anything, the following is needed:

- A clear description of what the problem is (a direct description, not an 
indirect reference to descriptions that have happened in the past).
- A clear proposal on what to do to fix the problem.
- A justification for the proposal demonstrating that the needs of all our 
users are acknowledged, understood and fully catered for, and the impact fully 
understood.

This last point above has been missing for me. Whenever this problem has been 
discussed, it has been brought to the table from a very narrow viewpoint, to 
solve a very specific problem that a specific person is having. The solutions 
have generally not taken into account the diversity of our user base, and 
usually solve a single problem while making other problems worse for others.

What has been missing is input from the major distributors of our software 
(Fedora, Ubuntu, Redhat, Debian, Apple, Windows, Linux from Scratch, etc), who 
I believe are probably going “httpd is a mature project, we have nothing to 
worry about”. I would recommend against making changes to our approach without 
soliciting the views of these people and making sure they’re all catered for.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[Nick Kew]

> 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

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

[Jim Jagielski]

> On Apr 30, 2018, at 12:26 PM, William A Rowe Jr  wrote:
> 
> On Thu, Apr 26, 2018 at 1:51 PM, William A Rowe Jr  > 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

[Eric Covener]

On Mon, Apr 30, 2018 at 2:21 PM, Paul Querna  wrote:
> FTR I support moving to this versioning model.
>
> I tend to think the best way to accomplish it, is to "just start doing
> it".   Tag 2.6.0.  Then tag 2.7.0 when there are new features, etc.
> Of course, our versioning docs don't support this model, but the docs
> are a reflection of reality 15 years ago more so than current
> attitudes.  Make the docs reflect reality as it changes rather than
> upfront votes unless absolutely necessary.

>
> Is a vote like the above required to just start making minor releases
> that contain new features, and making patch releases only contain bug
> fixes?

I think something is needed to avoid other parts of the team putting
enhancements into 2.4 at the same time, or from throwing up their
hands at the prospect of N streams / STATUS files.

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

[Paul Querna]

FTR I support moving to this versioning model.

I tend to think the best way to accomplish it, is to "just start doing
it".   Tag 2.6.0.  Then tag 2.7.0 when there are new features, etc.
Of course, our versioning docs don't support this model, but the docs
are a reflection of reality 15 years ago more so than current
attitudes.  Make the docs reflect reality as it changes rather than
upfront votes unless absolutely necessary.

Is a vote like the above required to just start making minor releases
that contain new features, and making patch releases only contain bug
fixes?



On Mon, Apr 30, 2018 at 9:26 AM, William A Rowe Jr  wrote:
> On Thu, Apr 26, 2018 at 1:51 PM, William A Rowe Jr 
> 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. I'm withdrawing
> any suggestion to find mechanisms to accomplish this goal.
>
>

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

[William A Rowe Jr]

On Thu, Apr 26, 2018 at 1:51 PM, William A Rowe Jr 
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. I'm withdrawing
any suggestion to find mechanisms to accomplish this goal.

[VOTE] Allow for defect fix releases at httpd

[William A Rowe Jr]

With discussion exchanged (across several years), and various
arguments presented, we should be able to adopt or reject the
first of several possible questions as a PMC. This is the meta-
question, any versioning discussion is irrelevant without specific
purpose or goal, and follow on questions would decide how the
PMC decides to solve this purpose;

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