Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Tue, Jan 24, 2017 at 5:22 AM, Reindl Harald  wrote:
>
> no, you are just a hypocrite trying to forbid others voice their opinion in
> their weay but not follow your own rules to always say critics nice and
> lovely and so you have no point to play internet police on mailing lists any
> longer

In the spirit of fairness, one for you too to keep the score even:
Keep stuff like this off of our lists.  It's not what we're all
subscribed for.

-- 
Eric Covener
cove...@gmail.com

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

https://www.youtube.com/watch?v=jKGjOE_7bYI

Re: [proposed] 2.4 Maintenance SIG

[Ruediger Pluem]

On 01/27/2017 04:21 PM, Eric Covener wrote:
> On Fri, Jan 27, 2017 at 10:07 AM, Nick Edwards  
> wrote:
>> You need some edumacation
> 
> We're well aware of his notoriety and their relationship.   I
> personally don't care about motives or backstory for off-topic
> shit-posting.
> 

+1

Regards

Rüdiger

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Fri, Jan 27, 2017 at 10:07 AM, Nick Edwards  wrote:
> You need some edumacation

We're well aware of his notoriety and their relationship.   I
personally don't care about motives or backstory for off-topic
shit-posting.

Re: [proposed] 2.4 Maintenance SIG

[Nick Edwards]

You need some edumacation, I've avoided getting involved in these comments
but I think this has to be said.

Reindl is a long time well known troll, a highly caustic and abusive one,
he's been kicked off more industry mailing lists than you've probably had
hot dinners for it, some other lists, he's just moderated on, but replies
constantly to posters in private, he also abuses them in private, this led
to him being blacklisted in a DNSBL that Noel happens to be one of the
maintainers of, so Reindl constantly tries to bait him, I heard they
mutually had agreement never to talk to each other, but Reindl does not
know how to keep promises, especially when others come out against Noel
like has gone on here, Reindl will always be in it (you vna see this from
his usual lame comment), I'm not  a real fan of Noel, I know him
personally, I worked for him in a national ISP - before he sacked me :)
He's a decent guy who will go out his way to help others, truth be told I
probably had a bout 10 warnings where most get 3 so he has a lot patience,
but if he has an opinion he will always express it and wont walk on cotton
wool in doing so, some respect him for it, others detest him for it, he's
always told me he doesnt care, because at least people know where they
stand with him.


as for Reindl, well, he cant see what hes doing wrong, despite being kicked
off all those lists, he's just a lost cause.
this ends your edumacation.


On Sat, Jan 28, 2017 at 12:11 AM, Eric Covener  wrote:

>
> On Fri, Jan 27, 2017 at 6:22 AM, Noel Butler 
> wrote:
>
>> I never object to any sensible opinion.
>>
>> Harry, you were warned never to reply or respond to me, because you know
>> what happens if you do, i'll assume you were off your meds again when you
>> clicked reply and forgot.
>>
> You both need to keep it topical and stop the mutual harassment.  Enough
> is enough.
>

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Fri, Jan 27, 2017 at 6:22 AM, Noel Butler  wrote:

> I never object to any sensible opinion.
>
> Harry, you were warned never to reply or respond to me, because you know
> what happens if you do, i'll assume you were off your meds again when you
> clicked reply and forgot.
>
You both need to keep it topical and stop the mutual harassment.  Enough is
enough.

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 24/01/2017 20:22, Reindl Harald wrote:

> Am 23.01.2017 um 02:52 schrieb Noel Butler: 
> 
>> Perhaps the only person who wont bend over and take it up the arse like
>> some people here expect, if I have an opinion, i'll voice it
> 
> no, you are just a hypocrite trying to forbid others voice their opinion in 
> their weay but not follow your own rules to always say critics nice and 
> lovely and so you have no point to play internet police on mailing lists any 
> longer

I never object to any sensible opinion. 

Harry, you were warned never to reply or respond to me, because you know
what happens if you do, i'll assume you were off your meds again when
you clicked reply and forgot. 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 23/01/2017 19:14, Stefan Eissing wrote:

> Am 23.01.2017 um 02:52 schrieb Noel Butler :
> 
> On 20/01/2017 07:45, Jacob Champion wrote:
> 
> On 01/19/2017 12:52 PM, Noel Butler wrote: Frequent releases set off alarms 
> in system admins minds, frequent
> releases give the view of unstable/unreliable software, and that is the
> largest cause of movement to an alternative. 
> So, the last [1] two [2] times you've pushed this viewpoint, you've been the 
> only one. You remain the only person I've ever known to hold this opinion, 
> and I speak as someone who maintained a long-term-

Perhaps the only person who wont bend over and take it up the arse like
some people here expect, if I have an opinion, i'll voice it, I have the
advantage of looking at this from also a system admins perspective, not
just a coders, and yes, they very well all too often differ. 
Your opinion and courageous behaviour is noted. Since I have the same
advantage as you and come to different conclusions, maybe there's a
hidden variable here somewhere.

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de [1]

And if we ask ten others in same vote as us, we'll probably end up with
ten more difference of opinions 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [2] and ODF [3] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.greenbytes.de
[2] http://www.adobe.com/
[3] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 24/01/2017 13:58, William A Rowe Jr wrote:

> On Sun, Jan 22, 2017 at 7:52 PM, Noel Butler  wrote:
> 
>> Perhaps the only person who wont bend over and take it up the arse like some 
>> people here expect, if I have an opinion, i'll voice it
> 
> Noel, your immediately prior post was an interesting example, although I fail 
>  
> to see how that particular example applies. When a project is dysfunctional  
> in multiple aspects, it is easy to pin the tail on the donkey of your 
> personally 
> most aggravating aspect. 
> 
> This specif post was not welcome, helpful, nor productive. 
> 
> You may want to press pause on sharing your voice for the time being, until  
> you find a way to express it in a more useful manner? Shouting doesn't help, 
> nor do expletives. If you need to be reminded again, our chair will take care 
>  
> of executing the unsubscribe function.

Riiight, So I shall only speak if I want to be a conformist and
agree?  If I have an opinion that differs you want me to shut up? 

riight. 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Reindl Harald]

Am 23.01.2017 um 02:52 schrieb Noel Butler:

Perhaps the only person who wont bend over and take it up the arse like
some people here expect, if I have an opinion, i'll voice it


no, you are just a hypocrite trying to forbid others voice their opinion 
in their weay but not follow your own rules to always say critics nice 
and lovely and so you have no point to play internet police on mailing 
lists any longer

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Sun, Jan 22, 2017 at 7:52 PM, Noel Butler  wrote:

> Perhaps the only person who wont bend over and take it up the arse like
> some people here expect, if I have an opinion, i'll voice it
>

Noel, your immediately prior post was an interesting example, although I
fail
to see how that particular example applies. When a project is dysfunctional
in multiple aspects, it is easy to pin the tail on the donkey of your
personally
most aggravating aspect.

This specif post was not welcome, helpful, nor productive.

You may want to press pause on sharing your voice for the time being, until
you find a way to express it in a more useful manner? Shouting doesn't help,
nor do expletives. If you need to be reminded again, our chair will take
care
of executing the unsubscribe function.

Re: [proposed] 2.4 Maintenance SIG

[Stefan Eissing]

> Am 23.01.2017 um 02:52 schrieb Noel Butler :
> 
> On 20/01/2017 07:45, Jacob Champion wrote:
> 
>> On 01/19/2017 12:52 PM, Noel Butler wrote:
>>> Frequent releases set off alarms in system admins minds, frequent
>>> releases give the view of unstable/unreliable software, and that is the
>>> largest cause of movement to an alternative.
>> 
>> So, the last [1] two [2] times you've pushed this viewpoint, you've been the 
>> only one. You remain the only person I've ever known to hold this opinion, 
>> and I speak as someone who maintained a long-term-
>>  
>  
> Perhaps the only person who wont bend over and take it up the arse like some 
> people here expect, if I have an opinion, i'll voice it, I have the advantage 
> of looking at this from also a system admins perspective, not just a coders, 
> and yes, they very well all too often differ.

Your opinion and courageous behaviour is noted. Since I have the same advantage 
as you and come to different conclusions, maybe there's a hidden variable here 
somewhere.

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 20/01/2017 07:45, Jacob Champion wrote:

> On 01/19/2017 12:52 PM, Noel Butler wrote: 
> 
>> Frequent releases set off alarms in system admins minds, frequent
>> releases give the view of unstable/unreliable software, and that is the
>> largest cause of movement to an alternative.
> 
> So, the last [1 [1]] two [2 [2]] times you've pushed this viewpoint, you've 
> been the only one. You remain the only person I've ever known to hold this 
> opinion, and I speak as someone who maintained a long-term-

Perhaps the only person who wont bend over and take it up the arse like
some people here expect, if I have an opinion, i'll voice it, I have the
advantage of looking at this from also a system admins perspective, not
just a coders, and yes, they very well all too often differ. 

.

In fact... you promised to bring others who agreed with you the next
time this came up: 

I did, but after an IRC channel was shown POV's and the hate and vitriol
I copped in email, they feared the same garbage from the same gutless
keyboard commandoes - despite the fact I know who they are (just like
script kiddies, they often are clueless at hiding their real identities)


and thanks for reminding me of that, they were so irrelevant to me i'd
actually forgotten all about them.

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [3] and ODF [4] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1]
https://lists.apache.org/thread.html/749c959edab1990ae56bc805db41b4a501ccbb6039400f379db02c7f@1447744388@%3Cdev.httpd.apache.org%3E
[2]
https://lists.apache.org/thread.html/efbb60b2c726c3c65abea01725f8b739722798a624128f3438a7bd8e@1458734298@%3Cdev.httpd.apache.org%3E
[3] http://www.adobe.com/
[4] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 20/01/2017 07:07, William A Rowe Jr wrote:

> On Thu, Jan 19, 2017 at 2:52 PM, Noel Butler  wrote: 
> On 20/01/2017 05:54, William A Rowe Jr wrote:
> 
> posts, I don't think you will find a single post where I suggested
> that there is an issue with the frequency of releases, but please
> feel free. 
> I believe that was me :)
> 
> You've put restated the argument again this month that if we
> don't enhance and add features, we will lose user share to
> another web server. 
> Frequent releases set off alarms in system admins minds, frequent releases 
> give the view of unstable/unreliable software, and that is the largest cause 
> of movement to an alternative.

I don't believe anyone has that opinion of nghttp2.

I think Tatsuhiro's release model for nghttp2 has been brilliant.

Monthly, there are new features (1.next.0). If there are regressions
between 1.next.0 releases, these are 1.current.1, 1.current.2 and
so on.

If the code works, he ships it. I'm impressed, and don't have any
negative perception that getting bug fixes out very quickly says
anything negative about nghttp2. 

I'm sure you'll find those who disagree with it too, as a clear example,
most seasoned admins would be aware of dovecots atrocious early track
record, releases were sub monthly, at times, even weekly, people stopped
upgrading because it was time consuming and "sick of it", there were
admins two years or more behind, and at some pretty big providers too,
phpmyadmin was worse, with at times bi-weekly releases,  Marc had myriad
of complaints, and eventually back off to updating ever couple months or
so unless critical exploit. Thats just two mainstream examples of how
dangerous it can be for release often mentality it might seem cool for
developers, but no so much for the very people those devs rely upon for
their software to remain relevant. 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/19/2017 12:52 PM, Noel Butler wrote:

Frequent releases set off alarms in system admins minds, frequent
releases give the view of unstable/unreliable software, and that is the
largest cause of movement to an alternative.


So, the last [1] two [2] times you've pushed this viewpoint, you've been 
the only one. You remain the only person I've ever known to hold this 
opinion, and I speak as someone who maintained a long-term-release-style 
distribution for my previous employer, shipping updates to customers who 
were often *incredibly* angry when we broke them.


I know what qualities I want from an upstream provider. "We sit on 
patches because we'll look bad if we release them too often" is not a 
desired quality.


In fact... you promised to bring others who agreed with you the next 
time this came up:


On 03/29/2016 12:37 AM, Noel Butler wrote:
> I accept you only see this as one opinion since they are not posting
> here, next time it comes up, I'll put a call on the other lists for
> every single one of them to sub to this list and put their thoughts
> forward :)

I trust you'll make good on this promise, so we can have a good 
conversation here. Until then, I don't really want to repeat the 
back-and-forth of the previous discussions.


--Jacob

[1] 
https://lists.apache.org/thread.html/749c959edab1990ae56bc805db41b4a501ccbb6039400f379db02c7f@1447744388@%3Cdev.httpd.apache.org%3E
[2] 
https://lists.apache.org/thread.html/efbb60b2c726c3c65abea01725f8b739722798a624128f3438a7bd8e@1458734298@%3Cdev.httpd.apache.org%3E

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski  wrote:
>
> Here's the real issue, as I see it. If there have been "recent
> breakages" it is not due to the release process, but rather
> the *testing* process. That is, not enough people testing
> 2.4-HEAD until we actually get close to a release. The idea
> should be that 2.4-HEAD is ALWAYS in a releasable and "runnable"
> state, it being RTC after all.

The idea should be that  *** TRUNK *** is always in a "run-able" and
releasable state, not withstanding legitimate showstoppers and some
multi-developer coordination in sorting out platform or other quirks
which are interdependent. RTC/CTR is a red herring. It simply flags
whether a couple of reviews occur before commit, not whether that
code deserves further review, or is subject to future veto, or may be
subject to further revision.

trunk/ should not be treated with any less caution than branches/2.4.x/,
that's what feature development branches are for.


From; http://httpd.apache.org/dev/guidelines.html

When to Commit a Change

Ideas must be review-then-commit; patches can be commit-then-review.
With a commit-then-review process, we trust that the developer doing
the commit has a high degree of confidence in the change. Doubtful
changes, new features, and large-scale overhauls need to be discussed
before being committed to a repository. Any change that affects the
semantics of arguments to configurable directives, significantly adds
to the runtime size of the program, or changes the semantics of an
existing API function must receive consensus approval on the mailing
list before being committed.

Each developer is responsible for notifying the mailing list and
adding an action item to STATUS when they have an idea for a new
feature or major change to propose for the product. The distributed
nature of the Apache project requires an advance notice of 48 hours in
order to properly review a major change -- consensus approval of
either the concept or a specific patch is required before the change
can be committed. Note that a member might veto the concept (with an
adequate explanation), but later rescind that veto if a specific patch
satisfies their objections. No advance notice is required to commit
singular bug fixes.

Related changes should be committed as a group, or very closely
together. Half-completed projects should not be committed unless doing
so is necessary to pass the baton to another developer who has agreed
to complete the project in short order. All code changes must be
successfully compiled on the developer's platform before being
committed.

The current source code tree should be capable of complete compilation
at all times. However, it is sometimes impossible for a developer on
one platform to avoid breaking some other platform when a change is
committed, particularly when completing the change requires access to
a special development tool on that other platform. If it is
anticipated that a given change will break some other platform, the
committer must indicate that in the commit log.

The committer is responsible for the quality of any third-party code
or documentation they commit to the repository. All software committed
to the repository must be covered by the Apache LICENSE or contain a
copyright and license that allows redistribution under the same
conditions as the Apache LICENSE.

A committed change must be reversed if it is vetoed by one of the
voting members and the veto conditions cannot be immediately satisfied
by the equivalent of a "bug fix" commit. The veto must be rescinded
before the change can be included in any public release.


From; http://httpd.apache.org/dev/release.html

When do I know if it is a good time to release?

Generally speaking, when some useful changes have been applied since
the last release and there are no showstoppers left to be resolved. It
is our convention to indicate showstoppers in the STATUS file in the
repository. A showstopper entry does not imply that a release cannot
be made -- it is more of an indication of current project consensus
and a reminder of what fixes are on the critical path. Each RM gets to
choose when to cut a release candidate based on the current content of
subversion. The entire PMC gets to decide whether or not that
candidate deserves to be released.

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 2:52 PM, Noel Butler  wrote:
>
> On 20/01/2017 05:54, William A Rowe Jr wrote:
>
>> posts, I don't think you will find a single post where I suggested
>> that there is an issue with the frequency of releases, but please
>> feel free.
>
> I believe that was me :)
>
>> You've put restated the argument again this month that if we
>> don't enhance and add features, we will lose user share to
>> another web server.
>
> Frequent releases set off alarms in system admins minds, frequent releases 
> give the view of unstable/unreliable software, and that is the largest cause 
> of movement to an alternative.

I don't believe anyone has that opinion of nghttp2.

I think Tatsuhiro's release model for nghttp2 has been brilliant.

Monthly, there are new features (1.next.0). If there are regressions
between 1.next.0 releases, these are 1.current.1, 1.current.2 and
so on.

If the code works, he ships it. I'm impressed, and don't have any
negative perception that getting bug fixes out very quickly says
anything negative about nghttp2.

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 20/01/2017 05:54, William A Rowe Jr wrote:

> posts, I don't think you will find a single post where I suggested
> that there is an issue with the frequency of releases, but please
> feel free.

I believe that was me :) 

> You've put restated the argument again this month that if we
> don't enhance and add features, we will lose user share to
> another web server.

Frequent releases set off alarms in system admins minds, frequent
releases give the view of unstable/unreliable software, and that is the
largest cause of movement to an alternative. 

I've stated my thoughts many times over the years... 

x.major for new features 

x.major.minor for bug fixes 

trunk snapshots for the x.major "new stuff" as a use at your own risk 

public release candidates advertised and made available for x.x.minor
"bug fixes" before any vote - this allows bug reporter to test further,
and time to see if the fix has introduced other problems before going
mainstream, but should exclude very critical security hole plugging,
which should go straight to release vote. 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

There is no such thing as "Jim's Releases" or "Bill's
Releases". The PMC votes on them and the release is
an action of the PMC. It's a PMC release.

As for why I do it: It's a chore. Mostly "thankless" due
to the drama one needs to endure and the fact that
you will be assured that at least someone will think
it is too late/too early, too minor/too major, etc...
So I do it as a service to the PMC and so that people
don't need to "worry" about it. I am more than willing
to help/mentor/guide anyone interested in wanting to
do it for themselves, as well, of course.

http://httpd.apache.org/dev/release.html

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

> On Jan 19, 2017, at 3:12 PM, Jacob Champion  wrote:
> 
> I don't agree with everything Bill is saying here, but to be fair to him: if 
> people are backporting new features and higher-risk changes to 2.4.x at the 
> same time an RM is trying to coordinate a bugfix-only release, I would 
> imagine that would be fairly difficult for *everyone*.
> 

Yep, agreed. That's why communication regarding releases, including
sufficient head's up is alway good.

If people want to see a quick 2.4.26, to address some of the
nits from 2.4.25, then I'm all for it. But we do have a
showstopper in place, iirc.

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/19/2017 07:49 AM, Jim Jagielski wrote:

You seem to be ignoring the times when bug-fixes, and regression-fix-only
patches themselves have resulted in regressions.


Sure, that does (and will continue to) happen. Every code change carries 
some risk, and no test suite is 100% perfect, but I don't think that's a 
reason not to separate bugfix and feature releases. (Plus, in my 
experience, the projects who ship bugfix lines tend to also be very 
quick about reverting bad fixes and immediately re-releasing when they 
accidentally break something else.)


It's a matter of risk management. If you know that every code change 
carries a non-zero risk of breaking deployments, and you separate 
low-risk changes (bugfixes) from higher-risk changes (functionality 
additions), then both end users and distro maintainers have a better 
time keeping up and managing their own risk. And different end users 
have different definitions of which risks are acceptable at which times.


Now, to your point about testing: a strong test suite shifts the entire 
risk "curve", so that functionality changes are safer to ship alongside 
bugfixes. So yes, I agree with you and we absolutely need to move in 
that direction. I've been trying to put my money where my mouth is 
there. But we're not there yet, and that means that many end users will 
view our functionality improvements as higher-risk. Rightly so IMO.


Even after we strengthen our test suite, there will still be value to 
end users in separating bugfix and feature releases, because it lets 
them decide what risks they're willing to take. What the test suite 
gives us then is the ability to roll out feature releases faster and 
faster without fear of regressions, so the lifetime of the low-risk 
bugfix lines can be shorter. It all feeds back, and everyone gets 
happier, and we can focus on cool stuff more.



Or when bug-fixes themselves devolve into grand-scale refactoring
which greatly introduce the very real probability of regressions.


Typically a bugfix release line wouldn't be receiving refactoring 
patches, just the smallest changes possible to fix bugs. The refactoring 
would happen in the feature release line.


(And the refactoring itself shouldn't be mixing code motion with 
functional changes to begin with; that's like rule #1. :) )



Handling regressions seems independent from where they come
from. Again, if we wish to release something quick that
just includes patches-as-of-this-date, then we certainly
can. But the 2 are not as tied-at-the-hip as you make it
to be.


I don't agree with everything Bill is saying here, but to be fair to 
him: if people are backporting new features and higher-risk changes to 
2.4.x at the same time an RM is trying to coordinate a bugfix-only 
release, I would imagine that would be fairly difficult for *everyone*.


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski  wrote:
>
>> On Jan 18, 2017, at 8:35 PM, Eric Covener  wrote:
>>
>> On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr  
>> wrote:
>>> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 
>>> that
>>> finally proves to be a workable upgrade for all httpd users?
>>
>> It sounds reasonable to me, but I think it's a bit of an oversell --
>> It's just going to be a little bit of stabilization.
>
> Agreed, but what did you expect? If anyone other than Bill
> would have proposed this, he would have complained that
> having such frequent releases is bad, etc...

Jim, are you really going to start ad hominem attacks again on dev?
I thought Eric asked nicely enough for this to desist.

Don't put words into my mouth. If you want to quote one of my
posts, I don't think you will find a single post where I suggested
that there is an issue with the frequency of releases, but please
feel free.

You'll find posts stating that the next release should contain 'X'
where 'X' was generally a security or regression fix that had not
received sufficient attention to backport.

I used to be of the mind that changing from 2.4 to 2.6 was some
radical change that our users would resist. I've come to the
conclusion that the pace of adoption of 2.0 from 1.3, or 2.2
from 2.0, or now from 2.2 to 2.4... little of this had to do with
the major or minor reversion. Users simply don't update,
except as provided by their environmental provider (some
OS distro or cpanel or other deployment schema.)

If anything, Bill and others have recently argued that version
numbers, even minor, and major, are cheap. We should use
them IMO.

> Here's the real issue, as I see it. If there have been "recent
> breakages" it is not due to the release process, but rather
> the *testing* process. That is, not enough people testing
> 2.4-HEAD until we actually get close to a release. The idea
> should be that 2.4-HEAD is ALWAYS in a releasable and "runnable"
> state, it being RTC after all.

My perception is that many enhancements get rammed into
the maintenance branch in the final days of a candidate
because new features are neat, instead of applying them
weeks ahead of a tag and ferreting out breakage across
the breadth of architectures and deployments that httpd
enjoys.

There are three reviewers. If things are going into a release
they either aren't getting sufficient review by those three
people, or three people are inadequate, or more likely...

Our testing process can never and will never capture 10%
of the various ways different developers and users have
deployed and customized their httpd environment, as is
illustrated in our bug tracker.

But having some approachable httpd.a.o/test/ pages that
get mentioned in our 'reporting bugs' pages might help
encourage users with more novel schemas to propose
some test case patches to our test framework? That
would increase coverage, it will always remain a fraction
of the anticipated and unexpected use cases.

> This is only, clearly, an attempt by Bill to commandeer the
> 2.4 release process, nothing more. Again, anyone is free
> to RM... there is no need to fabricate reasons to do so.
> If Bill wants to do a quick 2.4.26 with the current fixes
> then sure, why not. Especially if it will be "one we think is
> good", and we can pat Bill on the back for a job well done.

But the onus should not be on Bill's Releases to win some
feature-frozen and reduced-breakage/regression-fixing
packages for our users, while users expect Jim's Releases
to offer the newest (and potentially/eventually regression
inducing) features and enhancements.

You've put restated the argument again this month that if we
don't enhance and add features, we will lose user share to
another web server. I've restated the argument again this
month that unnecessary regressions cost us user share.
You restate above that a lack of testing causes regressions,
I am restating that adding features to maintenance releases
causes regressions.

This isn't my effort to commandeer the release process, it
is actually my third distinct proposal in a month to find some
major.minor.subversion schema which would be respected
and honored by the entire PMC. We can have a war of the
releases, that seems to be what you want. I would rather
see new committers and pmc members jump into the role
of RM - one that doesn't require years of dev list history
to anticipate whether the community will accept a release
tag at a particular point in time.

It isn't about Bill and Jim, Jim. It is about a community of
coders, who aren't listening well to the needs of one segment
or another of our users and consumers, and our use the
designated 'maintenance' release as a substitute for our
shipping any new releases.

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

You seem to be ignoring the times when bug-fixes, and regression-fix-only
patches themselves have resulted in regressions. Or when
bug-fixes themselves devolve into grand-scale refactoring
which greatly introduce the very real probability of regressions.

Handling regressions seems independent from where they come
from. Again, if we wish to release something quick that
just includes patches-as-of-this-date, then we certainly
can. But the 2 are not as tied-at-the-hip as you make it
to be.

Re: [proposed] 2.4 Maintenance SIG

[Yann Ylavic]

On Thu, Jan 19, 2017 at 8:22 AM, Stefan Eissing
 wrote:
>
> It will surprise no one that I like to release more often. OTOH I do
> not like to break things.
>
> The current release model clearly does not work well, in my limited
> experience over that last 15 months. Why?
>
> httpd is a rich product used in literally millions of different
> setups. This complexity is beyond our resources to test. Adding new
> functionality at the same time is just too much.

I tend to agree, we shouldn't refrain ourselves from adding
features/improvements to a release because there are also important
bug/security fixes in it.

>
> Personally, I like even/odd version schemes for stable/dev versions.
> But whatever works is fine. There are a lot of successful projects in
> and outside ASF with a good release scheme. Let's steal with pride
> one we think is good.

How about a release-able 2.5 (RTC still), forked from and
bugfix/security-synced with 2.4, where we could put anything
interesting/tested/working from trunk, with few (if any) API/ABI
garantees (motivated changes still!), until it becomes 2.6?
And then so on with 2.7, 2.6 is stable, 2.5 becomes immediatly
unmaintained, 2.4's EOL is announced...

I'd be fine fine we something like this, and I don't mind about
numbering or such, it's more about some process we could agree on.


Regards,
Yann.

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

> On Jan 18, 2017, at 8:35 PM, Eric Covener  wrote:
> 
> On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr  
> wrote:
>> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 
>> that
>> finally proves to be a workable upgrade for all httpd users?
> 
> It sounds reasonable to me, but I think it's a bit of an oversell --
> It's just going to be a little bit of stabilization.
> 

Agreed, but what did you expect? If anyone other than Bill
would have proposed this, he would have complained that
having such frequent releases is bad, etc...

Here's the real issue, as I see it. If there have been "recent
breakages" it is not due to the release process, but rather
the *testing* process. That is, not enough people testing
2.4-HEAD until we actually get close to a release. The idea
should be that 2.4-HEAD is ALWAYS in a releasable and "runnable"
state, it being RTC after all.

This is only, clearly, an attempt by Bill to commandeer the
2.4 release process, nothing more. Again, anyone is free
to RM... there is no need to fabricate reasons to do so.
If Bill wants to do a quick 2.4.26 with the current fixes
then sure, why not. Especially if it will be "one we think is
good", and we can pat Bill on the back for a job well done.

Re: [proposed] 2.4 Maintenance SIG

[Stefan Eissing]

> Am 19.01.2017 um 10:08 schrieb Reindl Harald :
> Am 19.01.2017 um 08:22 schrieb Stefan Eissing:
>> Distros seem to have realized the problem long ago and make their own httpd 
>> versions. First time I realized my "httpd 2.4.7" is not the 2.4.7 release 
>> was a WTF moment.
> 
> no, that applies to LTS distros and in that case of nearly any piece of 
> software and has nothing to do with httpd or the problems you are talking 
> about
> 
> httpd-2.4.6-45.el7.centos.x86_64
> mod_security-2.7.3-5.el7.x86_64
> 
> php-5.4.16-42.el7.x86_64:
> * Fr Aug 05 2016 Remi Collet  - 5.4.16-42
> - bz2: fix improper error handling in bzread() CVE-2016-5399
> 
> * Mo Aug 01 2016 Remi Collet  - 5.4.16-41
> - gd: fix integer overflow in _gd2GetHeader() resulting in
>  heap overflow CVE-2016-5766
> - gd: fix integer overflow in gdImagePaletteToTrueColor()
>  resulting in heap overflow CVE-2016-5767
> - mbstring: fix double free in _php_mb_regex_ereg_replace_exec
>  CVE-2016-5768
> 
> * Fr Jul 22 2016 Remi Collet  - 5.4.16-40
> - don't set environmental variable based on user supplied Proxy
>  request header CVE-2016-5385

Yes and no. The LTS releases try to do, what should (IMO) be a stable release 
branch from our side. The problem seems to me that our stable branch 2.2.x is 
too old for many and our only other releases, 2.4.x, has too many new, 
experimental and dangerous changes. So the LTS releases create a hybrid that is 
totally not managed by the httpd project. I have no clue what a httpd-2.4.6-45 
really is.


Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: [proposed] 2.4 Maintenance SIG

[Reindl Harald]

Am 19.01.2017 um 08:22 schrieb Stefan Eissing:

Distros seem to have realized the problem long ago and make their own httpd versions. 
First time I realized my "httpd 2.4.7" is not the 2.4.7 release was a WTF 
moment.


no, that applies to LTS distros and in that case of nearly any piece of 
software and has nothing to do with httpd or the problems you are 
talking about


httpd-2.4.6-45.el7.centos.x86_64
mod_security-2.7.3-5.el7.x86_64

php-5.4.16-42.el7.x86_64:
* Fr Aug 05 2016 Remi Collet  - 5.4.16-42
- bz2: fix improper error handling in bzread() CVE-2016-5399

* Mo Aug 01 2016 Remi Collet  - 5.4.16-41
- gd: fix integer overflow in _gd2GetHeader() resulting in
  heap overflow CVE-2016-5766
- gd: fix integer overflow in gdImagePaletteToTrueColor()
  resulting in heap overflow CVE-2016-5767
- mbstring: fix double free in _php_mb_regex_ereg_replace_exec
  CVE-2016-5768

* Fr Jul 22 2016 Remi Collet  - 5.4.16-40
- don't set environmental variable based on user supplied Proxy
  request header CVE-2016-5385

Re: [proposed] 2.4 Maintenance SIG

[Stefan Eissing]

> Am 19.01.2017 um 06:34 schrieb William A Rowe Jr :
> 
>> On Wed, Jan 18, 2017 at 7:35 PM, Eric Covener  wrote:
>>> On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr  
>>> wrote:
>>> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 
>>> that
>>> finally proves to be a workable upgrade for all httpd users?
>> 
>> It sounds reasonable to me, but I think it's a bit of an oversell --
>> It's just going to be a little bit of stabilization.
>> 
>> AFAICT so far there is:
>> 
>> One 2.4.25 regression committed:
>> 
>>  *) mod_proxy_{ajp,fcgi}: Fix a possible crash when reusing an established
>>backend connection, happening with LogLevel trace2 or higher configured,
>>or at any log level with compilers not detected as C99 compliant (e.g.
>>MSVC on Windows).  [Yann Ylavic]
>> 
>> One older regression listed as a showstopper:
>> 
>> *) PR 60576: 2.4.21 broke PHP-FPM with the patch to strip the bogus 
>> "proxy://"
>>prefix from SCRIPT_FILENAME. We need to revert to the previous behavior
>>ASAP to avoid any further hurdles with FCGI implementations while we 
>> figure
>>this out.
>> 
>> And a fix for an old bug that missed being backported until a bugzilla 
>> review:
>> 
>>  *) mod_proxy_fcgi, mod_fcgid: Fix crashes in ap_fcgi_encoded_env_len() when
>>modules add empty environment variables to the request. PR60275.
>>[]
>> 
>> Is there anything else we should list as a showstopper?
> 
> That is my underlying question; what else qualifies?
> 
> Win32 build fix of mod_status is already in 2.4.x branch two hours following
> the 2.4.25 re-tag, so that also is resolved.
> 
> Yann's proposal to accept the newly-prohibited obs-fold that we approved into
> 2.2.32 would also seem to qualify.
> 
> So far, I haven't heard from an httpd committer who is actually interested in
> our shipping such a release. I'd be happy to tag and roll, but this is more so
> a poll whether there is interest in having non-enhancement 2.4.x releases
> by the PMC/committer core, or whether there is a desire for a  fork for users
> who are not PMC members but are actively interested in pursuing a "stable"
> build.

It will surprise no one that I like to release more often. OTOH I do not like 
to break things.

The current release model clearly does not work well, in my limited experience 
over that last 15 months. Why?

httpd is a rich product used in literally millions of different setups. This 
complexity is beyond our resources to test. Adding new functionality at the 
same time is just too much.

That is why I am sticking to the separate releases of mod_http2 on github. 
Those get new code tested very frequently by adventourous users, finding bugs 
and giving suggestions. The http/2 implementation wouldn't be that far without 
them. 

Distros seem to have realized the problem long ago and make their own httpd 
versions. First time I realized my "httpd 2.4.7" is not the 2.4.7 release was a 
WTF moment.

Personally, I like even/odd version schemes for stable/dev versions. But 
whatever works is fine. There are a lot of successful projects in and outside 
ASF with a good release scheme. Let's steal with pride one we think is good.

Cheers, 

Stefan

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Wed, Jan 18, 2017 at 7:35 PM, Eric Covener  wrote:
> On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr  
> wrote:
>> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 
>> that
>> finally proves to be a workable upgrade for all httpd users?
>
> It sounds reasonable to me, but I think it's a bit of an oversell --
> It's just going to be a little bit of stabilization.
>
> AFAICT so far there is:
>
> One 2.4.25 regression committed:
>
>   *) mod_proxy_{ajp,fcgi}: Fix a possible crash when reusing an established
> backend connection, happening with LogLevel trace2 or higher configured,
> or at any log level with compilers not detected as C99 compliant (e.g.
> MSVC on Windows).  [Yann Ylavic]
>
> One older regression listed as a showstopper:
>
>  *) PR 60576: 2.4.21 broke PHP-FPM with the patch to strip the bogus 
> "proxy://"
> prefix from SCRIPT_FILENAME. We need to revert to the previous behavior
> ASAP to avoid any further hurdles with FCGI implementations while we 
> figure
> this out.
>
> And a fix for an old bug that missed being backported until a bugzilla review:
>
>   *) mod_proxy_fcgi, mod_fcgid: Fix crashes in ap_fcgi_encoded_env_len() when
> modules add empty environment variables to the request. PR60275.
> []
>
> Is there anything else we should list as a showstopper?

That is my underlying question; what else qualifies?

Win32 build fix of mod_status is already in 2.4.x branch two hours following
the 2.4.25 re-tag, so that also is resolved.

Yann's proposal to accept the newly-prohibited obs-fold that we approved into
2.2.32 would also seem to qualify.

So far, I haven't heard from an httpd committer who is actually interested in
our shipping such a release. I'd be happy to tag and roll, but this is more so
a poll whether there is interest in having non-enhancement 2.4.x releases
by the PMC/committer core, or whether there is a desire for a  fork for users
who are not PMC members but are actively interested in pursuing a "stable"
build.

Cheers,

Bill

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr  wrote:
> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 
> that
> finally proves to be a workable upgrade for all httpd users?

It sounds reasonable to me, but I think it's a bit of an oversell --
It's just going to be a little bit of stabilization.

AFAICT so far there is:

One 2.4.25 regression committed:

  *) mod_proxy_{ajp,fcgi}: Fix a possible crash when reusing an established
backend connection, happening with LogLevel trace2 or higher configured,
or at any log level with compilers not detected as C99 compliant (e.g.
MSVC on Windows).  [Yann Ylavic]

One older regression listed as a showstopper:

 *) PR 60576: 2.4.21 broke PHP-FPM with the patch to strip the bogus "proxy://"
prefix from SCRIPT_FILENAME. We need to revert to the previous behavior
ASAP to avoid any further hurdles with FCGI implementations while we figure
this out.

And a fix for an old bug that missed being backported until a bugzilla review:

  *) mod_proxy_fcgi, mod_fcgid: Fix crashes in ap_fcgi_encoded_env_len() when
modules add empty environment variables to the request. PR60275.
[]

Is there anything else we should list as a showstopper?

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Tue, Jan 3, 2017 at 2:18 AM, Graham Leggett  wrote:
> On 03 Jan 2017, at 2:11 AM, William A Rowe Jr  wrote:
>
>> So I'd like to know, in light of a perpetual chain of (often build and/or 
>> run-time breaking regression) enhancements, if there is support for a 
>> 2.4.24.x release chain during the 3.0 transition? And support for 
>> potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug 
>> fixes?
>>
>> It's clear this project doesn't agree, so the question twists to how we 
>> agree to disagree.
>
> Can you clarify the problem you’re trying to solve?

There are multiple recent breakages in httpd. The backport proposal to 2.4
extending mod_dav would have introduced yet another. Other features on
the table such as proxy protocol enhancement, or mod_status extensions
all introduce more and more opportunities to introduce yet another release
with regressions.

I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 that
finally proves to be a workable upgrade for all httpd users? Only bug fixes
which correct defects introduced during 2.4.x would be addressed. Then
skip on to 2.4.27 with new regressions, and repeat the mop-up process in
2.4.28, etc.

Most projects would call these 2.5.0 new features, 2.5.x regression and
bug fixes, 2.6.0 new features, 2.6.x regression and bug fixes etc.

But httpd seems to want to keep a unique numbering schema, because
other numbering conventions weren't invented here.

Is it really unreasonable to expect subsequent releases to not introduce
new errors and become more error-free between enchancement releases?

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Thu, Jan 5, 2017 at 12:50 PM, Jacob Champion  wrote:
> On 01/04/2017 11:55 AM, Graham Leggett wrote:
>>
>> On 04 Jan 2017, at 8:37 PM, Jacob Champion  wrote:
>>>
>>> So, there's 3k of the 20k. And remember, my point was that we can
>>> fix what I call "dead code" with good old fashioned legwork. I
>>> don't advocate trashing trunk, and I don't think having "dead code"
>>> is a disaster or a stain on anyone here. I just don't think it's
>>> appropriate to spin up an RC from trunk as-is.
>>
>>
>> Look for the discussion that occurred around November 2011 when v2.4
>> was released:
>>
>> http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x
>>
>>  We came to the same conclusion then.
>
>
> I started a longer reply to what you wrote earlier in the email, but I think
> I need to clear up any misunderstandings I have with this part first.
>
> From offlist discussions I've had with other committers (and Bill's recent
> reply to this thread), my understanding was that an alpha/beta branch would
> be forked from the current tip of trunk, followed by testing and additional
> feature work, until a .0 release is voted on.
>
> The conversation you linked to appears to modify that somewhat: we started
> tagging trunk directly with alpha/beta, and at some point decided to fork a
> 2.4.x from a mostly current trunk. It also adds the information that 2.4.x
> was still CTR, up to the .0 release. But in both cases, the statement "we
> plan to fork 2.6.x from a current-ish trunk commit" seems to hold up pretty
> well.
>
> Is that correct?

Following past practices, and a desire to reduce the amount of effort by
committers, I'd strongly object to a fork before 3.0 (or 2.6) is finalized.
It's a procedural-process sort of question, so it's a straightforward PMC
majority vote.

I'm also against forking at 3.0 or 2.6 until someone wants to introduce
an API breaking change, unless we solidify some new process for having
more predictable and frequent bug fix releases and split these from our
constant churn of feature changes. In that case, feature changes do map
well to trunk until there is a breaking ABI change, while we would need to
collect such bug fixes on a new branch.

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/04/2017 11:55 AM, Graham Leggett wrote:

On 04 Jan 2017, at 8:37 PM, Jacob Champion  wrote:

So, there's 3k of the 20k. And remember, my point was that we can
fix what I call "dead code" with good old fashioned legwork. I
don't advocate trashing trunk, and I don't think having "dead code"
is a disaster or a stain on anyone here. I just don't think it's
appropriate to spin up an RC from trunk as-is.


Look for the discussion that occurred around November 2011 when v2.4
was released:

http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x

 We came to the same conclusion then.


I started a longer reply to what you wrote earlier in the email, but I 
think I need to clear up any misunderstandings I have with this part first.


From offlist discussions I've had with other committers (and Bill's 
recent reply to this thread), my understanding was that an alpha/beta 
branch would be forked from the current tip of trunk, followed by 
testing and additional feature work, until a .0 release is voted on.


The conversation you linked to appears to modify that somewhat: we 
started tagging trunk directly with alpha/beta, and at some point 
decided to fork a 2.4.x from a mostly current trunk. It also adds the 
information that 2.4.x was still CTR, up to the .0 release. But in both 
cases, the statement "we plan to fork 2.6.x from a current-ish trunk 
commit" seems to hold up pretty well.


Is that correct?

--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 04 Jan 2017, at 8:37 PM, Jacob Champion  wrote:

>> Can you give us an example of this dead code?
> 
> In modules/ alone (I haven't looked at server/ yet, and don't plan to today), 
> after ignoring build-related files and stripping the svn-diff context, there 
> are twenty *thousand* lines of diff between 2.4 and trunk.
> 
> Now, here's the problem. I can't prove which parts of these are dead and 
> which aren't; I can't prove that *any* of it is dead, really. I only know 
> that there are twenty thousand lines of unreviewed code changes in modules/. 
> That's significant, IMO.

I need to stop you there - none of this code is unreviewed.

“CTR” means “commit then review”, it basically means “write the code, make sure 
it works and integrates properly, then commit it - an email will be sent to the 
project, and people review that diff". Either that code is uncontroversial and 
accepted as is, or it will be challenged.

This review part isn’t a joke. People like Rüdiger Plüm will pick apart and 
judge every line, and you have to defend your changes. Some changes can take a 
long time to get right. This could mean polishing the code as provided, or 
removing it entirely and trying again.

Then, if you want to get to v2.4, you have to pass RTC “review then commit”. 
The change is then reviewed again a second time, this time asking the question 
“will this break existing users in any way”. We don’t change ABI on any stable 
branch (ie v2.4 or below).

> Here are three cherry-picked modules which, to me, seem to be in limbo. 
> Whether we consider this code "dead" or "sleeping" or "on temporary hiatus" 
> or "untouched because it's perfect already" is probably heavily subjective.
> 
> 1) mod_policy
> 
> 1300 lines, added in 2011, last meaningful code change in 2012, no tests that 
> I can find. (However, it does have public documentation.)

That waits for v2.6.

mod_policy is itself a set of tests.

> 2) mod_serf
> 
> 1100 lines, added in 2007, last meaningful code change in 2011, no tests, no 
> public documentation.
> 
> 3) mod_apreq2
> 
> 1000 lines, added in 2011, no meaningful code changes since addition, no 
> tests, no documented public release of libapreq2 since 2010. (It does have 
> public documentation. And it seems like there's history here I don't 
> understand. Maybe it lives somewhere else and was being folded into httpd?)

This is historical.

When v2.4 got released, the changes in mod_serf and mod_apreq2 were deemed to 
be not ready enough for v2.4. When v2.4 got created mod_serf and mod_apreq2 
were not brought forward. If they’re not ready now, the same thing can happen.

> So, there's 3k of the 20k. And remember, my point was that we can fix what I 
> call "dead code" with good old fashioned legwork. I don't advocate trashing 
> trunk, and I don't think having "dead code" is a disaster or a stain on 
> anyone here. I just don't think it's appropriate to spin up an RC from trunk 
> as-is.

Look for the discussion that occurred around November 2011 when v2.4 was 
released:

http://smtp.grokbase.com/t/apache/dev/11bb6wswq2/branched-httpd-2-4-x

We came to the same conclusion then.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

To your questions of history;

On Wed, Jan 4, 2017 at 12:37 PM, Jacob Champion  wrote:
>
> 3) mod_apreq2
>
> 1000 lines, added in 2011, no meaningful code changes since addition, no
> tests, no documented public release of libapreq2 since 2010. (It does have
> public documentation. And it seems like there's history here I don't
> understand. Maybe it lives somewhere else and was being folded into httpd?)

Yes, this comes from the Apache Perl (mod_perl) project (also
Apache::Test which they still maintain and release.) As does the Win32
flavor of apxs.

> So, there's 3k of the 20k. And remember, my point was that we can fix what I
> call "dead code" with good old fashioned legwork. I don't advocate trashing
> trunk, and I don't think having "dead code" is a disaster or a stain on
> anyone here. I just don't think it's appropriate to spin up an RC from trunk
> as-is.

Historically, e.g. between 2.0 and 2.2, we have had a series of public
alphas followed by betas labeled 2.1.x-alpha (and -beta), until it was
clean enough to go GA as 2.2.0.

I doubt anyone is thinking of going straight to any 2.6 or 3.0 release
without a series of 2.5-alpha/beta releases. We especially considered
third party module authors when we moved to that schema, so that they
would have the opportunity to adjust for any API or behavior changes
long before a GA announcement, including a feedback loop to ask us to
improve that API for their consumption. Few seem to have taken us up
on that opportunity, but we can always hope for more participation the
next cycle.

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/04/2017 12:13 AM, Graham Leggett wrote:

On 03 Jan 2017, at 10:47 PM, Jacob Champion  wrote:


I don't feel that trunk is a dead branch, but I do think there is dead code in 
trunk.


Can you give us an example of this dead code?


In modules/ alone (I haven't looked at server/ yet, and don't plan to 
today), after ignoring build-related files and stripping the svn-diff 
context, there are twenty *thousand* lines of diff between 2.4 and trunk.


Now, here's the problem. I can't prove which parts of these are dead and 
which aren't; I can't prove that *any* of it is dead, really. I only 
know that there are twenty thousand lines of unreviewed code changes in 
modules/. That's significant, IMO.


Here are three cherry-picked modules which, to me, seem to be in limbo. 
Whether we consider this code "dead" or "sleeping" or "on temporary 
hiatus" or "untouched because it's perfect already" is probably heavily 
subjective.


1) mod_policy

1300 lines, added in 2011, last meaningful code change in 2012, no tests 
that I can find. (However, it does have public documentation.)


2) mod_serf

1100 lines, added in 2007, last meaningful code change in 2011, no 
tests, no public documentation.


3) mod_apreq2

1000 lines, added in 2011, no meaningful code changes since addition, no 
tests, no documented public release of libapreq2 since 2010. (It does 
have public documentation. And it seems like there's history here I 
don't understand. Maybe it lives somewhere else and was being folded 
into httpd?)


So, there's 3k of the 20k. And remember, my point was that we can fix 
what I call "dead code" with good old fashioned legwork. I don't 
advocate trashing trunk, and I don't think having "dead code" is a 
disaster or a stain on anyone here. I just don't think it's appropriate 
to spin up an RC from trunk as-is.


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/04/2017 12:13 AM, Graham Leggett wrote:

On 03 Jan 2017, at 10:47 PM, Jacob Champion  wrote:


I don't feel that trunk is a dead branch, but I do think there is dead code in 
trunk.


Can you give us an example of this dead code?


I'm working to answer this question now. My original assertion is based 
on the fact that a reallyall-build of trunk does not start for the test 
suite without dumping core.


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/04/2017 08:42 AM, William A Rowe Jr wrote:

On Wed, Jan 4, 2017 at 9:47 AM, Graham Leggett  wrote:

That’s not dead code, that’s just the difference between v2.4 and trunk.


So long as the project chooses not to release it, it sits in a repository DoA.


To a certain extent we'll have to do that, because breaking changes 
can't be backported, and we shouldn't put huge breaking changes on a 
short release cadence. I'm not counting unreleased breaking changes in 
my assertion of "dead code", and I certainly don't think all of the 
2.4->trunk diff is dead and useless.


(I'm currently working on reviewing the diff to answer Graham's 
question; it'll take a little while.)



One of the interesting assertions is that C-T-R -> Trunk, R-T-C Trunk
-> 2.4 is the correct and customary state of contributing to httpd.

At one time this project operated in C-T-R -> Trunk -> Release mode.
It would be productive to return to that model.


I'm not following this jump. If anything, I'm not a fan of CTR to begin 
with for a security-critical code base, *especially* if we're 
considering spinning a release candidate out of a branch that has 
unreviewed patches in it, but that's pulling the conversation in 
directions it doesn't need to go right now. I will bring that back up 
later, in a more appropriate thread.



The goal of R-T-C on 2.4.x is simply to eliminate (unsuccessfully) ABI
breakage and regressions between subversion releases.


The goal of RTC should be to *review* -- to ensure code quality, catch 
problems that aren't caught with tests (ABI, security, etc.), and so on. 
Catching regressions should be the goal of the test suite.


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Wed, Jan 4, 2017 at 9:47 AM, Graham Leggett  wrote:
> On 04 Jan 2017, at 3:16 PM, William A Rowe Jr  wrote:
>
>>> Can you give us an example of this dead code?
>>
>> svn diff --ignore-properties --no-diff-deleted -x --ignore-all-space
>> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/server
>> https://svn.apache.org/repos/asf/httpd/httpd/trunk/server
>> svn diff --ignore-properties --no-diff-deleted -x --ignore-all-space
>> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/modules
>> https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules
>
> That’s not dead code, that’s just the difference between v2.4 and trunk.

So long as the project chooses not to release it, it sits in a repository DoA.

One of the interesting assertions is that C-T-R -> Trunk, R-T-C Trunk
-> 2.4 is the correct and customary state of contributing to httpd.

At one time this project operated in C-T-R -> Trunk -> Release mode.
It would be productive to return to that model.

The goal of R-T-C on 2.4.x is simply to eliminate (unsuccessfully) ABI
breakage and regressions between subversion releases.

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 04 Jan 2017, at 3:16 PM, William A Rowe Jr  wrote:

>> Can you give us an example of this dead code?
> 
> svn diff --ignore-properties --no-diff-deleted -x --ignore-all-space
> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/server
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/server
> svn diff --ignore-properties --no-diff-deleted -x --ignore-all-space
> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/modules
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules

That’s not dead code, that’s just the difference between v2.4 and trunk.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Wed, Jan 4, 2017 at 2:13 AM, Graham Leggett  wrote:
> On 03 Jan 2017, at 10:47 PM, Jacob Champion  wrote:
>
>> I don't feel that trunk is a dead branch, but I do think there is dead code 
>> in trunk.
>
> Can you give us an example of this dead code?

svn diff --ignore-properties --no-diff-deleted -x --ignore-all-space
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/server
https://svn.apache.org/repos/asf/httpd/httpd/trunk/server
svn diff --ignore-properties --no-diff-deleted -x --ignore-all-space
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/modules
https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

> On Jan 4, 2017, at 3:13 AM, Graham Leggett  wrote:
> 
> On 03 Jan 2017, at 10:47 PM, Jacob Champion  wrote:
> 
>> I don't feel that trunk is a dead branch, but I do think there is dead code 
>> in trunk.
> 
> Can you give us an example of this dead code?
> 

I tend to see some of the code related to stuff in httpd-2.4's
STATUS files that are "STALLED" or "BEING WORKED" as not so
much "dead code" but code that needs more eyes on it.

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 03 Jan 2017, at 10:47 PM, Jacob Champion  wrote:

> I don't feel that trunk is a dead branch, but I do think there is dead code 
> in trunk.

Can you give us an example of this dead code?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/03/2017 06:07 AM, William A Rowe Jr wrote:

If trunk/ is a dead fork, it may be time for httpd to admit this, trash
it and re-fork trunk from 2.4.x branch.


I don't feel that trunk is a dead branch, but I do think there is dead 
code in trunk. The CTR policy contributes to that, IMO, but we can solve 
that problem with elbow grease. A re-fork feels like overkill...


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Jacob Champion]

On 01/02/2017 04:11 PM, William A Rowe Jr wrote:

So far, discussions are polarized on a single axis...

East: Let's work on 3.0; whatever is going on in 2.4 won't distract me,
I won't spend time reviewing enhancements, because 3.0 is the goal.

West: Let's keep the energy going on 2.4 enhancements, I won't spend
time on 3.0 usability because it isn't ready or necessary.


Can I put my checkmark in "neither"?

I'm in favor of a 2.6 and/or 3.0 release when it's obvious that the 
benefits to us and our users outweigh the costs of spinning up another 
release branch, and at this point in time I'm not convinced we've 
reached that tipping point.


Until we get there, I would like to continue backporting as much as 
possible from trunk. Those who are following the 2.4.x branches in 
production will get the most benefit; those who are locked to a distro 
snapshot will miss out, sure, but they're missing out anyway. (We can 
probably help *marginally* with that by separating bugfix releases from 
feature releases. There's another in-progress thread with that suggestion.)



So I'd like to know, in light of a perpetual chain of (often build
and/or run-time breaking regression) enhancements, if there is support
for a 2.4.24.x release chain during the 3.0 transition? And support for
potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious
bug fixes?


I'll echo Eric here -- if it's necessary, sure. I'm not convinced it's 
necessary yet. There are other ways to ensure quality releases, and 
there are two or three threads actively discussing them, and I'll be 
actively committing time to pursue some of them.


--Jacob

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

Bill, your Email client is messed-up again, as related to
how it handles copy/pasted text in replies.

> On Jan 3, 2017, at 9:07 AM, William A Rowe Jr  wrote:
> 
> On Jan 3, 2017 02:19, "Graham Leggett"  wrote:
> 
> > Can you clarify the problem you’re trying to solve?
> > 
> > v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a 
> > very large architecture change (for example, the > addition of filters in 
> > v1.x to v2.x), we move to 3.0.
> >
> > Is there a very large architecture change planned by anybody?
> >
> > In my experience, things that felt initially like big changes have actually 
> > turned out to be rather modest changes that are > still possible to 
> > backport to v2.4 without an issue. For this reason I haven’t seen a reason 
> > to push very hard for v2.6, > > never mind v3.0.
> 
> I do, the very specific problem is that trunk/, and therefore all 
> more-than-modest (or just neglected) contributions are now four years stale 
> and abandoned.
> 
> A certain way to push off contributors is to ignore their patch submissions. 
> The second method is to commit them to a dead fork.
> 
> If trunk/ is a dead fork, it may be time for httpd to admit this, trash it 
> and re-fork trunk from 2.4.x branch.

Who said this? Who even implied it? And how do you align what
you just wrote with your complaints when people try to "encourage"
backports of stuff in trunk to 2.4.x?

There are some things in trunk that admittedly can't be backported,
and those, if worthwhile, should be reason and rationale for
getting httpd-next out.

The issue, if I may be so bold, is that some people likely
don't want to spend the time and trouble backporting because
other people use that as an opportunity to shout out "No more
enhancements on 2.4! You are wasting your time!" and who, after
all, wants to deal with the potential drama?

Personally, I would <3 to see the additional async stuff
in people's hands asap.

> 
> Beyond this, see the recent appeal for major.minor breaking change wish list 
> on trunk/STATUS, that is a different thread for you to chime in on.
> 
> Back to topic, who is interested in a stable release chain, since 2.4.x has 
> not been that?

IMO, 2.4.x has been that. I see no real justification
to suggest otherwise.

Re: [proposed] 2.4 Maintenance SIG

[Steffen]

>Nobody built on Windows prior to the release so 
>we had a re-roll. 

Please contact me before a release, so I can test. 

Steffen AL



--- Begin Message  
Group: gmane.comp.apache.devel 
MsgID: 

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 03 Jan 2017, at 4:07 PM, William A Rowe Jr  wrote:

> Can you clarify the problem you’re trying to solve?
> 
> v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a 
> very large architecture change (for example, the addition of filters in v1.x 
> to v2.x), we move to 3.0.
> 
> Is there a very large architecture change planned by anybody?
> 
> In my experience, things that felt initially like big changes have actually 
> turned out to be rather modest changes that are still possible to backport to 
> v2.4 without an issue. For this reason I haven’t seen a reason to push very 
> hard for v2.6, never mind v3.0.
> 
> I do, the very specific problem is that trunk/, and therefore all 
> more-than-modest (or just neglected) contributions are now four years stale 
> and abandoned.
> 
> A certain way to push off contributors is to ignore their patch submissions. 
> The second method is to commit them to a dead fork.

I’m not following this logic.

The rules are patches are committed to trunk first, and therefore trunk is 
never dead by definition. People either backport the change to v2.4, or they 
wait for 2.6. The backport to v2.4 happens immediately, waiting for v2.6 either 
means “I’m happy to wait for v2.6” or it means “I’m not happy to wait, so let’s 
release v2.6”.

This is how it has always been, and I see no problem with this pattern.

> If trunk/ is a dead fork, it may be time for httpd to admit this, trash it 
> and re-fork trunk from 2.4.x branch.

We would obviously never do this, at to do so would treat our contributors with 
contempt.

> Beyond this, see the recent appeal for major.minor breaking change wish list 
> on trunk/STATUS, that is a different thread for you to chime in on.
> 
> Back to topic, who is interested in a stable release chain, since 2.4.x has 
> not been that?

I still don’t understand the problem you’re trying to solve, v2.4.x has 
certainly been a very effective stable release chain. Or more accurately, I do 
not see any problem that cannot be solved by our current process, which is a 
choice between the following:

- backport the stuff to v2.4; otherwise
- release v2.6 and continue.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

On Jan 3, 2017 02:19, "Graham Leggett"  wrote:


Can you clarify the problem you’re trying to solve?

v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a
very large architecture change (for example, the addition of filters in
v1.x to v2.x), we move to 3.0.

Is there a very large architecture change planned by anybody?

In my experience, things that felt initially like big changes have actually
turned out to be rather modest changes that are still possible to backport
to v2.4 without an issue. For this reason I haven’t seen a reason to push
very hard for v2.6, never mind v3.0.


I do, the very specific problem is that trunk/, and therefore all
more-than-modest (or just neglected) contributions are now four years stale
and abandoned.

A certain way to push off contributors is to ignore their patch
submissions. The second method is to commit them to a dead fork.

If trunk/ is a dead fork, it may be time for httpd to admit this, trash it
and re-fork trunk from 2.4.x branch.

Beyond this, see the recent appeal for major.minor breaking change wish
list on trunk/STATUS, that is a different thread for you to chime in on.

Back to topic, who is interested in a stable release chain, since 2.4.x has
not been that?

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Mon, Jan 2, 2017 at 7:11 PM, William A Rowe Jr  wrote:
> So I'd like to know, in light of a perpetual chain of (often build and/or
> run-time breaking regression) enhancements, if there is support for a
> 2.4.24.x release chain during the 3.0 transition? And support for
> potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug
> fixes?

Not personally in favor of it, but would help maintain it if that's
what the community wants.

I don't recall much breakage in 2.4 over the past 6 months, much less
breakage that would have impeded anyones work for a significant amount
of time.  Nobody built on Windows prior to the release so we had a
re-roll.  I don't think the corrective action here is a new service
stream.

-- 
Eric Covener
cove...@gmail.com

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

> On Jan 2, 2017, at 7:11 PM, William A Rowe Jr  wrote:
> 
> So far, discussions are polarized on a single axis...
> 
> East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I 
> won't spend time reviewing enhancements, because 3.0 is the goal.
> 
> West: Let's keep the energy going on 2.4 enhancements, I won't spend time on 
> 3.0 usability because it isn't ready or necessary.
> 

I have not really seen things as polarized as you make out, at
least as represented by the "West" strawman.

Re: [proposed] 2.4 Maintenance SIG

[Graham Leggett]

On 03 Jan 2017, at 2:11 AM, William A Rowe Jr  wrote:

> So far, discussions are polarized on a single axis...
> 
> East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I 
> won't spend time reviewing enhancements, because 3.0 is the goal.
> 
> West: Let's keep the energy going on 2.4 enhancements, I won't spend time on 
> 3.0 usability because it isn't ready or necessary.
> 
> There is a disconnect, because 'East' folks can't actually put up with the 
> breakage introduced by enhancements they can't review on 2.4, but all feel 
> responsible to keeping 2.4 usable to EOL.
> 
> So I'd like to know, in light of a perpetual chain of (often build and/or 
> run-time breaking regression) enhancements, if there is support for a 
> 2.4.24.x release chain during the 3.0 transition? And support for potentially 
> 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug fixes?
> 
> It's clear this project doesn't agree, so the question twists to how we agree 
> to disagree.

Can you clarify the problem you’re trying to solve?

v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a very 
large architecture change (for example, the addition of filters in v1.x to 
v2.x), we move to 3.0.

Is there a very large architecture change planned by anybody?

In my experience, things that felt initially like big changes have actually 
turned out to be rather modest changes that are still possible to backport to 
v2.4 without an issue. For this reason I haven’t seen a reason to push very 
hard for v2.6, never mind v3.0.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

[proposed] 2.4 Maintenance SIG

[William A Rowe Jr]

So far, discussions are polarized on a single axis...

East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I
won't spend time reviewing enhancements, because 3.0 is the goal.

West: Let's keep the energy going on 2.4 enhancements, I won't spend time
on 3.0 usability because it isn't ready or necessary.

There is a disconnect, because 'East' folks can't actually put up with the
breakage introduced by enhancements they can't review on 2.4, but all feel
responsible to keeping 2.4 usable to EOL.

So I'd like to know, in light of a perpetual chain of (often build and/or
run-time breaking regression) enhancements, if there is support for a
2.4.24.x release chain during the 3.0 transition? And support for
potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious
bug fixes?

It's clear this project doesn't agree, so the question twists to how we
agree to disagree.