You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Daniel Ruggeri <dr...@primary.net> on 2018/04/18 22:43:18 UTC
So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was:
2.4.3x regression w/SSL vhost configs)]
On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
> Hours, yes, but we've had a willing RM, who has automated even
> more of this than Jim or I had, and has a very hard time finding
> any target to point to. E.g. "ok, that looks like the right resolution
> to the last of the regressions... let's..." ... "...oh there are all these
> other shiny objects in STATUS... rock-n-roll!!!"
> ...
What's particularly interesting to me, as I follow the conversation in
my usual lurker-mode, is that Bill hit the nail on the head with this
observation. I was waiting for the dust to settle to run through the
scripts again for another T&R and release vote... but am not totally
sure if we're ready. (mea culpa: my brain melted as I tried to follow
the merging discussion so instead started parsing for "Yep. We're good
now.")
My current read on the conversation is that we're happy (or maybe just
content) with the SSL merging fixes and we should prep to ship 2.4.34 as
a fix. Does anyone disagree?
--
Daniel Ruggeri
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Daniel Ruggeri <dr...@primary.net>.
I don't think Stefan is proposing that we mindlessly ship based on an
arbitrary set of dates. That'd be too.... corporate :-)
I think in the past you mentioned that we have had features/fixes/Good
Stuff(tm) that was probably *ready*... just not yet released. I do
recall a few times where there have been fixes in 2.4.x branch that I
was frustrated as a user (burdened with the knowledge of a developer)
for having to wait to hit a release... so my main objective with the
automation is to simply make it simple to do a release so we aren't
entirely dependent on you and Bill to get those fixes/features/whatever
it may be into our users' hands.
Referring to the other message I just sent. I want to stress the fact
that now, with a few commands and *some* manual work (mostly when there
are CVEs to address), anyone can do a release. There's value in this -
especially given the fact that I truly did pore through and intensively
examine/internalize the documentation yet STILL managed to burn a
version number due to rookie mistakes. The third option along with
status quo or automation would be for the next unfortunate committer to
stumble through the process themselves and, possibly, make the same
mistakes I did.
Besides, heck... as you say, this is Open Source. We're volunteers and
this is the kind of stuff I actually do like to work on. CI/CD and the
like are a Good Thing :thumbsup:
Specifically to your question, Stefan... you beat me to it. Since the
last time I executed the release, I put in a quarterly reminder on my
calendar to check STATUS and help shuffle a release out the door if
there are no showstoppers and if we had added anything that looked cool.
I plan to stick by that schedule and also try to keep a pulse on the
project for times where we should ship a release sooner.
--
Daniel Ruggeri
On 4/19/2018 8:06 AM, Jim Jagielski wrote:
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
>
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
>
>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>>
>> Daniel,
>>
>> would you find it feasible to make a 2.4 release every first Tuesday of the month? Other projects have excellent experiences with such release timings.
>>
>> I‘d expect this would let us focus on the changes („one more week until release“), take off pressure („we can do it in the next release“), avoid meta discussions („is this a good time?“) and let us streamline the test/release work with changes in process/automation with a higher motivation.
>>
>> Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
>>
>> Cheers, Stefan
>>
>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
>>>
>>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>>>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
>>>> Hours, yes, but we've had a willing RM, who has automated even
>>>> more of this than Jim or I had, and has a very hard time finding
>>>> any target to point to. E.g. "ok, that looks like the right resolution
>>>> to the last of the regressions... let's..." ... "...oh there are all these
>>>> other shiny objects in STATUS... rock-n-roll!!!"
>>>> ...
>>> What's particularly interesting to me, as I follow the conversation in
>>> my usual lurker-mode, is that Bill hit the nail on the head with this
>>> observation. I was waiting for the dust to settle to run through the
>>> scripts again for another T&R and release vote... but am not totally
>>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>>> the merging discussion so instead started parsing for "Yep. We're good
>>> now.")
>>>
>>> My current read on the conversation is that we're happy (or maybe just
>>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>>> a fix. Does anyone disagree?
>>>
>>> --
>>> Daniel Ruggeri
>>>
Re: Start using RCs
Posted by Micha Lenk <mi...@lenk.info>.
On 04/23/2018 07:24 PM, Paul Querna wrote:
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
>
> Contains a much more verbose... non-semver versioning scheme.
Interesting. Did you realize this already covers the recently suggested
use of release candidates? Even on the 2.4.x branch...
Regards,
Micha
Re: Start using RCs
Posted by Paul Querna <pa...@querna.org>.
On Mon, Apr 23, 2018 at 10:10 AM, Micha Lenk <mi...@lenk.info> wrote:
> On 04/23/2018 06:33 PM, William A Rowe Jr wrote:
>>
>> On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk <mi...@lenk.info> wrote:
>>>
>>> On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:
>>>>
>>>> We have a history, as well as a published "agreement" on what minor
>>>> version numbering means.
>>>
>>>
>>> Just to make sure I am on the same page, would you mind to make that
>>> explicit? Where is that published?
>>
>>
>> http://httpd.apache.org/dev/release.html
>
>
> The only paragraph on that page that contains the word "minor" is the second
> one in the Introduction section. It isn't very verbose either. Am I missing
> something obvious?
>
> Regards,
> Micha
https://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
Contains a much more verbose... non-semver versioning scheme.
Re: Start using RCs
Posted by Micha Lenk <mi...@lenk.info>.
On 04/23/2018 06:33 PM, William A Rowe Jr wrote:
> On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk <mi...@lenk.info> wrote:
>> On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:
>>> We have a history, as well as a published "agreement" on what minor
>>> version numbering means.
>>
>> Just to make sure I am on the same page, would you mind to make that
>> explicit? Where is that published?
>
> http://httpd.apache.org/dev/release.html
The only paragraph on that page that contains the word "minor" is the
second one in the Introduction section. It isn't very verbose either. Am
I missing something obvious?
Regards,
Micha
Re: Start using RCs
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Apr 23, 2018 at 11:12 AM, Micha Lenk <mi...@lenk.info> wrote:
> Hi Jim,
>
> On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:
>> We have a history, as well as a published "agreement" on what minor
>> version numbering means.
>
> Just to make sure I am on the same page, would you mind to make that
> explicit? Where is that published?
http://httpd.apache.org/dev/release.html
Re: Start using RCs
Posted by Micha Lenk <mi...@lenk.info>.
Hi Jim,
On Fri, Apr 20, 2018 at 08:54:09AM -0400, Jim Jagielski wrote:
> We have a history, as well as a published "agreement" on what minor
> version numbering means.
Just to make sure I am on the same page, would you mind to make that
explicit? Where is that published?
> Our module eco-system is huge and we need to factor/consider not only
> the big players, but also the solitary developers who have modules. It
> is a long, long history and if/when we need to reconsider versioning,
> the impact will not be insignificant.
>
> [...]
> Again, it is all in balance, and likely we've just not achieved that
> lately due to the extreme complexities of the eco-system around,
> internal, external and dependent upon us.
But isn't the very purpose of the major.minor construct (that renders
all modules incompatible on a minor version bump) to get a handle on the
"extreme complexity" of the eco-system? If so, is the major.minor
construct used correctly to get the most out of it?
Regards,
Micha
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Mark Blackman <ma...@exonetric.com>.
> On 20 Apr 2018, at 01:39, Daniel Ruggeri <dr...@primary.net> wrote:
>
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).
Presumably most/all of that toil can be automated away as you have started doing, so that human intervention is only required where human judgement is actually required? Does httpd have some massive CD/CI pipeline in the background I don’t see or could it do with one?
- Mark
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 24, 2018 at 6:36 AM, Daniel Ruggeri <DR...@primary.net> wrote:
>
> One more thing to point out that I didn't explicitly say in the previous message is that this suggestion implies the release branch regularly gets cut from trunk (rather than growing and diverging on its own). This helps avoid "locking" features in trunk indefinitely because of the time between Maj.Min bumps.
+1... the new development branch has the greatest activity level. Any patch
branch is picked from that current activity.
Any major rev refactoring should be proven up in a sandbox first. If it can
be automated (e.g. function renames or mass function updates as we had
for APLOGNO()), all the better to test and re-test against trunk.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Daniel Ruggeri <DR...@primary.net>.
On April 23, 2018 11:30:07 AM CDT, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <dr...@primary.net>
>wrote:
>>
>> The more I think about it, the more I *really* like a semver-ish
>> approach where major represents the ABI that will not be broken,
>minor
>> represents the feature set (for backwards compatibility) and patch
>> represents forward-compatible changes/fixes. This may be, in spirit,
>> what you are suggesting. I'd further add that no directives are added
>in
>> patch releases, but minor releases would be fair game. How we choose
>to
>> maintain that behind the scenes is a thought exercise. Given that
>most
>> of our users get httpd from distros, I'd be in favor of having only
>two
>> long-lived branches: trunk and release. The distros are already
>taking
>> the point-release they want and curating fixes/changes for it, so
>they
>> will be doing what they do regardless of our direction.
>
>Thought exercise... if it is decided that version 3.5.x added an all
>around
>nice set of features, and we had platform maintainers as committers who
>wanted to keep backporting to that tree at this project, well... they
>could
>elect to maintain that version as a long lived branch and collaborate
>on
>it while we went on our merry way through 3.15.0, even 4.1.x as a
>group.
>
>In other words, wherever we have three committers who will cultivate a
>long lived release, they can do that. This doesn't differ from how a
>few
>individuals kept 2.0, and later, 2.2 alive for a significant period of
>time
>after the next major release. When interest cooled, each was retired.
Of course - this being Open Source and we being volunteers, we work on what we want to work on :-). I generally see that doesn't happen much for projects operating this way, though. My perception is that typically once 2.7.0 is released, work dies off quickly for 2.6.x. As mentioned elsethread, what the distros are signing up for (right or wrong) is to put a stake in the ground on a certain version and to select specific patches for fixes alone. If we were to do the same, it may be a duplication of effort.
Now... That doesn't preclude us from operating like Ubuntu does, for example, with their LTS style releases where we do "2.6.x will get fixes only for X years, but 2.7+ will get features until the next LTS cut". I think that idea may be what you have in mind. So, in that world we have three long lived branches: trunk, release and LTS. I can see us operating in that way... and to make backports less cumbersome, we could further declare that a fix accepted in STATUS for the LTS branch is accepted also into the release branch.
One more thing to point out that I didn't explicitly say in the previous message is that this suggestion implies the release branch regularly gets cut from trunk (rather than growing and diverging on its own). This helps avoid "locking" features in trunk indefinitely because of the time between Maj.Min bumps.
--
Daniel Ruggeri
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <dr...@primary.net> wrote:
>
> The more I think about it, the more I *really* like a semver-ish
> approach where major represents the ABI that will not be broken, minor
> represents the feature set (for backwards compatibility) and patch
> represents forward-compatible changes/fixes. This may be, in spirit,
> what you are suggesting. I'd further add that no directives are added in
> patch releases, but minor releases would be fair game. How we choose to
> maintain that behind the scenes is a thought exercise. Given that most
> of our users get httpd from distros, I'd be in favor of having only two
> long-lived branches: trunk and release. The distros are already taking
> the point-release they want and curating fixes/changes for it, so they
> will be doing what they do regardless of our direction.
Thought exercise... if it is decided that version 3.5.x added an all around
nice set of features, and we had platform maintainers as committers who
wanted to keep backporting to that tree at this project, well... they could
elect to maintain that version as a long lived branch and collaborate on
it while we went on our merry way through 3.15.0, even 4.1.x as a group.
In other words, wherever we have three committers who will cultivate a
long lived release, they can do that. This doesn't differ from how a few
individuals kept 2.0, and later, 2.2 alive for a significant period of time
after the next major release. When interest cooled, each was retired.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Eric Covener <co...@gmail.com>.
On Sun, Apr 22, 2018 at 2:03 PM, Daniel Ruggeri <DR...@primary.net> wrote:
> Unhelpful for whom? If we ship the latest, secure config from the single release branch, we wouldn't be encumbered by having to use tricks for fixes.
I think we're getting off into the weeds a bit here. My belief is
that most users extend the configuration, and different users want
different behaviors even if they use the same distribution. Most
users at any given time want no changes at all beyond the required
security fixes.
I don't feel like "directives" are even a secondary source of any of
the recent regressions. In reality, gating changes behind directives
would have likely avoided a good deal of the regressions if we had a
different tolerance for such a thing or the impacts could have been
anticipated.
That's why I don't see any benefit in prohibiting new directives in a
reworked service stream being managed as more stable, even without
weighing any of the other tradeoffs. I see only risk in that fixes can
only be delivered when they are safe for 100% of users 100% of the
time.
> In the same vein of thought, if it is disruptive to a config, that signals a minor bump. Patch changes must be forward compatible.
This doesn't really differ from the status quo.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Daniel Ruggeri <DR...@primary.net>.
Unhelpful for whom? If we ship the latest, secure config from the single release branch, we wouldn't be encumbered by having to use tricks for fixes. Most end users who get their custom build from the distros would get the same custom directive-level fixes applicable to them (ie: they know what's in the build so don't have to do such gymnastics).
In the same vein of thought, if it is disruptive to a config, that signals a minor bump. Patch changes must be forward compatible.
--
Daniel Ruggeri
On April 22, 2018 12:32:24 PM CDT, Eric Covener <co...@gmail.com> wrote:
>On Sun, Apr 22, 2018 at 1:31 PM, Eric Covener <co...@gmail.com>
>wrote:
>>> I'd further add that no directives are added in
>>> patch releases, but minor releases would be fair game.
>>
>> I don't think that kind of rule would be helpful, it just pushes
>> configuration into defines, per-request environment variables, etc
>> which are worse (because unlike a directive, you can't tell if
>they're
>> present)
>
>Of fixes which may be disruptive, that is.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Eric Covener <co...@gmail.com>.
On Sun, Apr 22, 2018 at 1:31 PM, Eric Covener <co...@gmail.com> wrote:
>> I'd further add that no directives are added in
>> patch releases, but minor releases would be fair game.
>
> I don't think that kind of rule would be helpful, it just pushes
> configuration into defines, per-request environment variables, etc
> which are worse (because unlike a directive, you can't tell if they're
> present)
Of fixes which may be disruptive, that is.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Eric Covener <co...@gmail.com>.
> I'd further add that no directives are added in
> patch releases, but minor releases would be fair game.
I don't think that kind of rule would be helpful, it just pushes
configuration into defines, per-request environment variables, etc
which are worse (because unlike a directive, you can't tell if they're
present)
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri <dr...@primary.net>
wrote:
> Yeah - I think my main concern is really just around the backporting
> process with STATUS and how that will have issues scaling across many
> branches. Further, as each branch deviates, it becomes more of a
> cognitive exercise for developers to figure out if the fix in branch XYZ
> is applicable and the same in ABC.
>
> The more I think about it, the more I *really* like a semver-ish
> approach where major represents the ABI that will not be broken, minor
> represents the feature set (for backwards compatibility) and patch
> represents forward-compatible changes/fixes.
Apache Subversion takes the patch number much more literally. They are
merely fixes to behavior defined in the minor release. The API/ABI is never
touched during a patch release. You could build against 1.7.13, then
install 1.7.0 and your code works against it. Then upgrade svn to 1.7.20
and it still works. Downgrade to 1.7.5 ... you get the picture.
I see several issues with the recent threads of discussion:
* How releases are numbered, and what guarantees are made relative to those
numbers
* What kinds of gating of features/fixes is defined by the process?
* How are branches created/maintained, relative to the above
Classic httpd numbering can certainly be made to work (empirically: it
has). semver is well-documented, understood, and downstream users would not
need to understand our quirks. It does kind of impose decisions on gating
of features, though (Q2 above).
It is unclear what problem is being solved. It seems like the unpredictable
feature set of 2.4.x. And/or when to stop loading features into that, and
start a 2.6.x series. (or 3.0?)
Cheers,
-g
ps. my vote is for semver and strict controls on patch releases. chew
through release numbers. they are cheap. downstream will pick one release
and run with that. it doesn't matter to them if we have a new minor every
six months (which means new features, which distros won't pick those
features from patch releases anyways; may as well move them to a minor)
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Daniel Ruggeri <dr...@primary.net>.
Yeah - I think my main concern is really just around the backporting
process with STATUS and how that will have issues scaling across many
branches. Further, as each branch deviates, it becomes more of a
cognitive exercise for developers to figure out if the fix in branch XYZ
is applicable and the same in ABC.
The more I think about it, the more I *really* like a semver-ish
approach where major represents the ABI that will not be broken, minor
represents the feature set (for backwards compatibility) and patch
represents forward-compatible changes/fixes. This may be, in spirit,
what you are suggesting. I'd further add that no directives are added in
patch releases, but minor releases would be fair game. How we choose to
maintain that behind the scenes is a thought exercise. Given that most
of our users get httpd from distros, I'd be in favor of having only two
long-lived branches: trunk and release. The distros are already taking
the point-release they want and curating fixes/changes for it, so they
will be doing what they do regardless of our direction. For
administrators building httpd themselves, they have control of when to
pull the trigger on a build and what they build, so I don't think they
would be harmed by such a change. Hopefully this isn't considered a
caustic statement (it is not intended to be), but I feel that this would
bring our versioning practices more in line with what most OSS projects
are doing these days and also avoid some of the issues managing several
branches. (I really am digging this idea :-) I'm glad folks have
proposed it...)
--
Daniel Ruggeri
On 4/20/2018 12:08 AM, William A Rowe Jr wrote:
> Let me counter with this... Rather than break the API every m.n
> release, what if we roll on to 2.6 with no ABI breakage, or resolve
> with impumity everything wrong in 3.0 with a firm commitment not to
> break it again till 4.0?
>
> This might be the root problem of our trying to !is versioning semantics.
>
>
> On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri <druggeri@primary.net
> <ma...@primary.net>> wrote:
>
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd
> expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a
> release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches
> and a
> bugfix applicable to all (or worse... a security fix that would
> dictate
> all should be released/disclosed at the same time).
>
> --
> Daniel Ruggeri
>
> On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> > I don't disagree with RC's entirely, or the mechanism you
> suggest, but
> > that isn't what I read as proposed.
> >
> > Our issue is that every httpd must be distinguished, we won't ship
> > four tarballs all claiming 2.4.34 (GA). Which one is the person
> > complaining about? Are we back to SHA signature of the source
> tarball
> > (that isn't even assuredly what they built the binary from?)
> >
> > We can decorate the rc in the versioning, but that isn't part of
> 2.4.x
> > API, unless we swap out the "-dev" string tag for an "-rc#" value.
> >
> > It is not reasonable to lock a branch for an indeterminate length of
> > time. Branching the RC into what becomes the final release, and
> making
> > it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> > might help discourage disruptive backports, but there is no
> suggestion
> > yet of what is acceptable, either on such a frozen main branch or rc
> > branch.
> >
> > In fact our policy reflects that two competing release candidates is
> > an entire valid and even expected situation, and any process that
> > further blocks this should be firmly rebuffed.
> >
> > As it reads so far the proposal is the way we do things, now
> > conserving subversion numbers as precious, if only to reenforce a
> > stake in the ground that version major and minor numbers are
> similarly
> > precious, (which they are not.)
> >
> > With the addition of freezing changes on 2.4.x branch for a time we
> > succeed in impeading progress towards version .next, while not
> > otherwise changing the status quo.
> >
> > What you suggest is yet another thing, based on forking the RC
> release
> > branch, and I haven't seen that accepted by the committee yet.
> >
> > On Thu, Apr 19, 2018, 16:43 David Zuelke <dzuelke@salesforce.com
> <ma...@salesforce.com>
> > <mailto:dzuelke@salesforce.com <ma...@salesforce.com>>>
> wrote:
> >
> > The main difference is that you have a release branch in
> which fixes
> > to bugs or regressions found during 2.4.x RCs can be made,
> while work
> > on 2.4.(x+1) can continue in the main 2.4 branch.
> >
> > Another benefit is that people who do automated builds (e.g.
> me) can
> > grep for "RC" in the version number and have it fetch from
> > https://dist.apache.org/repos/dist/dev/httpd/ instead.
> >
> > The changelogs are more readable as well, because it's
> obvious which
> > intermediary RC releases belong together. If you look at
> > https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> > indication that e.g. 2.4.31 was never released.
> >
> >
> > On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> > <wrowe@rowe-clan.net <ma...@rowe-clan.net>
> <mailto:wrowe@rowe-clan.net <ma...@rowe-clan.net>>> wrote:
> > > What possible improvement occurs if there is no branch
> discipline
> > > on 2.4.x development? We just echoed effectively your
> proposal,
> > > using numbers rather than RC designations, and still .33
> has this
> > > host of issues. With no release since .29, the branch was
> in this
> > > continuous state of flux between 2.4.30 and 2.4.33.
> Testing the
> > > 2.4.30 release did not result in a better, eventual
> 2.4.31, testing
> > > .31 didn't result in a better .32, and even the final .33 had
> > its own
> > > issues.
> > >
> > > This would have been precisely the same outcome between RC1
> > > and RC4, if the project doesn't keep the branch stable for
> even the
> > > week or months required to craft a successful release, and
> if that
> > > occurs on 2.4.x branch, that is an interruption of effort
> towards
> > > release n+1, frustrating contributors.
> > >
> > > Note we don't publish anything not approved by the PMC, so
> > > there would be the same "vote" to release an RC.
> > >
> > > Net <-> net, this is the status quo which failed us so
> badly this
> > > past winter (now with alphabetic characters!)
> > >
> > >
> > > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski
> <jim@jagunet.com <ma...@jagunet.com>
> > <mailto:jim@jagunet.com <ma...@jagunet.com>>> wrote:
> > >> The idea is encouraging and fostering a broader test
> audience.
> > >>
> > >>
> > >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr
> > <wrowe@rowe-clan.net <ma...@rowe-clan.net>
> <mailto:wrowe@rowe-clan.net <ma...@rowe-clan.net>>> wrote:
> > >>
> > >> Unless I misunderstand...
> > >>
> > >> 2.4.30-RC1 (rejected)
> > >> 2.4.30-RC2 (our .31, rejected)
> > >> 2.4.30-RC3 (our .32, rejected)
> > >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> > >>
> > >> With all the associated changes in between, no actual
> change in
> > branch
> > >> management, scope, feature creep, etc?
> > >>
> > >> This sounds like dressing up the status quo with
> different labels.
> > >>
> > >>
> > >>
> > >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski
> <jim@jagunet.com <ma...@jagunet.com>
> > <mailto:jim@jagunet.com <ma...@jagunet.com>>> wrote:
> > >>>
> > >>>
> > >>>
> > >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr
> > <wrowe@rowe-clan.net <ma...@rowe-clan.net>
> <mailto:wrowe@rowe-clan.net <ma...@rowe-clan.net>>>
> > >>> > wrote:
> > >>> >
> > >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski
> > <jim@jagunet.com <ma...@jagunet.com>
> <mailto:jim@jagunet.com <ma...@jagunet.com>>> wrote:
> > >>> >> With all this in mind, should we try to set things up so
> > that the
> > >>> >> next release cycle uses the concept of RCs?
> > >>> >>
> > >>> >> If so, and if people like, I can come up with a baseline
> > >>> >> proposal on the process for us to debate and come to
> > >>> >> some consensus on.
> > >>> >
> > >>> > Would you define an RC? What changes are allowable in that
> > branch?
> > >>>
> > >>>
> > >>> The idea is that right now we take an existing state in SVN
> > >>> and tag it as, for example, 2.4.121. We then vote on
> that tag
> > >>> and the artifacts released from that tag. No work is done on
> > >>> the 2.4 branch while testing is done so that we ensure that
> > >>> the SVN rev on branch == the one for the tag
> > >>
> > >>
> > >> Not necessary to freeze; a tag can always be applied to an
> > older rev.
> > >>
> > >>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> > >>> vote does not pass, we continue on the 2.4 branch, fix the
> > >>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
> > >>>
> > >>> If the vote does pass we tag the branch, which is still
> == RC#
> > >>> at this stage, as 2.4.121 (ap_release.h mods included). We
> > >>> still even at this stage test and vote on the release as
> we have
> > >>> for decades. If it passes, we release. If not, for some
> reason,
> > >>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> > >>> the above.
> > >>>
> > >>> This is the overall idea... more flesh to be added.
> > >>
> > >>
> >
>
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 20, 2018, at 8:28 AM, Micha Lenk <mi...@lenk.info> wrote:
>
> Hi Jim,
>
> On 04/20/2018 01:46 PM, Jim Jagielski wrote:
>> Where numbers and versioning DOES matter is how it affects
>> distributors and vendors of httpd and the entire module eco-system.
> No, it doesn't. There are way too many variants of versioning schemes out there in use by so many OSS projects that the distributors and vendors need to be prepared to encounter any variant you can imagine.
>
We have a history, as well as a published "agreement" on what minor version numbering means. Our module eco-system is huge and we need to factor/consider not only the big players, but also the solitary developers who have modules. It is a long, long history and if/when we need to reconsider versioning, the impact will not be insignificant.
> What matters is quality (here I do agree with you). A versioning scheme can help to establish certain rules of what to do and more importantly what to *not* do on a given version pattern or branch. And with the current rate of successful releases, apparently the current rules either were not enforced well enough or otherwise were not good enough and thus need to be changed. A new versioning scheme then could help to establish new, hopefully better rules.
Or just change the goalposts... if, as you say, our current version-scheme rules don't work as far as limiting/controlling what we can do (which I don't agree with, btw), then simply replacing it with another version-scheme likely won't do anything as well.
Again, I don't think numbers or names are the issue at hand, at core, but rather, maybe, overconfidence in how we have been doing release QA and testing. For example, and I am certainly guilty of this, the original concept was that "new stuff" was put in trunk, and allowed to mellow and age, for a "bit" at least, to get a feel for how well it works. After "awhile", when things looked like it was "ready for prime time", it would be proposed for backport. Today, right after something is committed to trunk there is almost invariably, in the next commit, a backport proposal for it to be in 2.4. Now for bug fixes, etc, that likely makes some level of sense, but lately, it seems like committing to trunk is just a tic-mark.
Again, it is all in balance, and likely we've just not achieved that lately due to the extreme complexities of the eco-system around, internal, external and dependent upon us.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Micha Lenk <mi...@lenk.info>.
Hi Jim,
On 04/20/2018 01:46 PM, Jim Jagielski wrote:
> Where numbers and versioning DOES matter is how it affects
> distributors and vendors of httpd and the entire module eco-system.
No, it doesn't. There are way too many variants of versioning schemes
out there in use by so many OSS projects that the distributors and
vendors need to be prepared to encounter any variant you can imagine.
What matters is quality (here I do agree with you). A versioning scheme
can help to establish certain rules of what to do and more importantly
what to *not* do on a given version pattern or branch. And with the
current rate of successful releases, apparently the current rules either
were not enforced well enough or otherwise were not good enough and thus
need to be changed. A new versioning scheme then could help to establish
new, hopefully better rules.
Just my 2¢.
Regards,
Micha
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 20, 2018, at 1:08 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Let me counter with this... Rather than break the API every m.n release, what if we roll on to 2.6 with no ABI breakage, or resolve with impumity everything wrong in 3.0 with a firm commitment not to break it again till 4.0?
Doesn't that break our understanding/"contract" with all external module developers and ISV? Up until now, minor has always indicated ABI changes which means, real world, you need to provide a different module build for each minor version. Now we would be saying "Nope, not in this case"
That seems, to me, worse than what we have now. Plus, it does nothing to satisfy the concerns about "quality" of what is released in any way.
Again, IMO, it's not about numbers, or what we call it, for US. It about QA, testing and being more sensitive to regression and wholesale refactoring on stuff that is going to be released. Where numbers and versioning DOES matter is how it affects distributors and vendors of httpd and the entire module eco-system.
Just my 2c
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Let me counter with this... Rather than break the API every m.n release,
what if we roll on to 2.6 with no ABI breakage, or resolve with impumity
everything wrong in 3.0 with a firm commitment not to break it again till
4.0?
This might be the root problem of our trying to !is versioning semantics.
On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri <dr...@primary.net> wrote:
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).
>
> --
> Daniel Ruggeri
>
> On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> > I don't disagree with RC's entirely, or the mechanism you suggest, but
> > that isn't what I read as proposed.
> >
> > Our issue is that every httpd must be distinguished, we won't ship
> > four tarballs all claiming 2.4.34 (GA). Which one is the person
> > complaining about? Are we back to SHA signature of the source tarball
> > (that isn't even assuredly what they built the binary from?)
> >
> > We can decorate the rc in the versioning, but that isn't part of 2.4.x
> > API, unless we swap out the "-dev" string tag for an "-rc#" value.
> >
> > It is not reasonable to lock a branch for an indeterminate length of
> > time. Branching the RC into what becomes the final release, and making
> > it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> > might help discourage disruptive backports, but there is no suggestion
> > yet of what is acceptable, either on such a frozen main branch or rc
> > branch.
> >
> > In fact our policy reflects that two competing release candidates is
> > an entire valid and even expected situation, and any process that
> > further blocks this should be firmly rebuffed.
> >
> > As it reads so far the proposal is the way we do things, now
> > conserving subversion numbers as precious, if only to reenforce a
> > stake in the ground that version major and minor numbers are similarly
> > precious, (which they are not.)
> >
> > With the addition of freezing changes on 2.4.x branch for a time we
> > succeed in impeading progress towards version .next, while not
> > otherwise changing the status quo.
> >
> > What you suggest is yet another thing, based on forking the RC release
> > branch, and I haven't seen that accepted by the committee yet.
> >
> > On Thu, Apr 19, 2018, 16:43 David Zuelke <dzuelke@salesforce.com
> > <ma...@salesforce.com>> wrote:
> >
> > The main difference is that you have a release branch in which fixes
> > to bugs or regressions found during 2.4.x RCs can be made, while work
> > on 2.4.(x+1) can continue in the main 2.4 branch.
> >
> > Another benefit is that people who do automated builds (e.g. me) can
> > grep for "RC" in the version number and have it fetch from
> > https://dist.apache.org/repos/dist/dev/httpd/ instead.
> >
> > The changelogs are more readable as well, because it's obvious which
> > intermediary RC releases belong together. If you look at
> > https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> > indication that e.g. 2.4.31 was never released.
> >
> >
> > On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> > <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> > > What possible improvement occurs if there is no branch discipline
> > > on 2.4.x development? We just echoed effectively your proposal,
> > > using numbers rather than RC designations, and still .33 has this
> > > host of issues. With no release since .29, the branch was in this
> > > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > > .31 didn't result in a better .32, and even the final .33 had
> > its own
> > > issues.
> > >
> > > This would have been precisely the same outcome between RC1
> > > and RC4, if the project doesn't keep the branch stable for even the
> > > week or months required to craft a successful release, and if that
> > > occurs on 2.4.x branch, that is an interruption of effort towards
> > > release n+1, frustrating contributors.
> > >
> > > Note we don't publish anything not approved by the PMC, so
> > > there would be the same "vote" to release an RC.
> > >
> > > Net <-> net, this is the status quo which failed us so badly this
> > > past winter (now with alphabetic characters!)
> > >
> > >
> > > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <jim@jagunet.com
> > <ma...@jagunet.com>> wrote:
> > >> The idea is encouraging and fostering a broader test audience.
> > >>
> > >>
> > >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr
> > <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> > >>
> > >> Unless I misunderstand...
> > >>
> > >> 2.4.30-RC1 (rejected)
> > >> 2.4.30-RC2 (our .31, rejected)
> > >> 2.4.30-RC3 (our .32, rejected)
> > >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> > >>
> > >> With all the associated changes in between, no actual change in
> > branch
> > >> management, scope, feature creep, etc?
> > >>
> > >> This sounds like dressing up the status quo with different labels.
> > >>
> > >>
> > >>
> > >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <jim@jagunet.com
> > <ma...@jagunet.com>> wrote:
> > >>>
> > >>>
> > >>>
> > >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr
> > <wrowe@rowe-clan.net <ma...@rowe-clan.net>>
> > >>> > wrote:
> > >>> >
> > >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski
> > <jim@jagunet.com <ma...@jagunet.com>> wrote:
> > >>> >> With all this in mind, should we try to set things up so
> > that the
> > >>> >> next release cycle uses the concept of RCs?
> > >>> >>
> > >>> >> If so, and if people like, I can come up with a baseline
> > >>> >> proposal on the process for us to debate and come to
> > >>> >> some consensus on.
> > >>> >
> > >>> > Would you define an RC? What changes are allowable in that
> > branch?
> > >>>
> > >>>
> > >>> The idea is that right now we take an existing state in SVN
> > >>> and tag it as, for example, 2.4.121. We then vote on that tag
> > >>> and the artifacts released from that tag. No work is done on
> > >>> the 2.4 branch while testing is done so that we ensure that
> > >>> the SVN rev on branch == the one for the tag
> > >>
> > >>
> > >> Not necessary to freeze; a tag can always be applied to an
> > older rev.
> > >>
> > >>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> > >>> vote does not pass, we continue on the 2.4 branch, fix the
> > >>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
> > >>>
> > >>> If the vote does pass we tag the branch, which is still == RC#
> > >>> at this stage, as 2.4.121 (ap_release.h mods included). We
> > >>> still even at this stage test and vote on the release as we have
> > >>> for decades. If it passes, we release. If not, for some reason,
> > >>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> > >>> the above.
> > >>>
> > >>> This is the overall idea... more flesh to be added.
> > >>
> > >>
> >
>
>
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Daniel Ruggeri <dr...@primary.net>.
I'm not sure where in the conversation to add this, but I do want to
point out a mechanical concern.
If we end up with API and feature freeze on branch 2.4, then we'd expect
to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
branch) can't get a feature or the next great thing because of a
required API incompatible change. We would then kick out 2.8, 2.10 and
so on and so forth. This seems like it would satisfy both the
keep-the-stuff-stable as well as the give-users-new-stuff "sides".
Mechanically, this can become tiresome for a volunteer as we work
through the STATUS ceremony for each of the branches. I remember that
being less than enjoyable when 2.0, 2.2 and 2.4 were all release
branches. I'm fearful of a future where we may have five branches and a
bugfix applicable to all (or worse... a security fix that would dictate
all should be released/disclosed at the same time).
--
Daniel Ruggeri
On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> I don't disagree with RC's entirely, or the mechanism you suggest, but
> that isn't what I read as proposed.
>
> Our issue is that every httpd must be distinguished, we won't ship
> four tarballs all claiming 2.4.34 (GA). Which one is the person
> complaining about? Are we back to SHA signature of the source tarball
> (that isn't even assuredly what they built the binary from?)
>
> We can decorate the rc in the versioning, but that isn't part of 2.4.x
> API, unless we swap out the "-dev" string tag for an "-rc#" value.
>
> It is not reasonable to lock a branch for an indeterminate length of
> time. Branching the RC into what becomes the final release, and making
> it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> might help discourage disruptive backports, but there is no suggestion
> yet of what is acceptable, either on such a frozen main branch or rc
> branch.
>
> In fact our policy reflects that two competing release candidates is
> an entire valid and even expected situation, and any process that
> further blocks this should be firmly rebuffed.
>
> As it reads so far the proposal is the way we do things, now
> conserving subversion numbers as precious, if only to reenforce a
> stake in the ground that version major and minor numbers are similarly
> precious, (which they are not.)
>
> With the addition of freezing changes on 2.4.x branch for a time we
> succeed in impeading progress towards version .next, while not
> otherwise changing the status quo.
>
> What you suggest is yet another thing, based on forking the RC release
> branch, and I haven't seen that accepted by the committee yet.
>
> On Thu, Apr 19, 2018, 16:43 David Zuelke <dzuelke@salesforce.com
> <ma...@salesforce.com>> wrote:
>
> The main difference is that you have a release branch in which fixes
> to bugs or regressions found during 2.4.x RCs can be made, while work
> on 2.4.(x+1) can continue in the main 2.4 branch.
>
> Another benefit is that people who do automated builds (e.g. me) can
> grep for "RC" in the version number and have it fetch from
> https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
> The changelogs are more readable as well, because it's obvious which
> intermediary RC releases belong together. If you look at
> https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> indication that e.g. 2.4.31 was never released.
>
>
> On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> > What possible improvement occurs if there is no branch discipline
> > on 2.4.x development? We just echoed effectively your proposal,
> > using numbers rather than RC designations, and still .33 has this
> > host of issues. With no release since .29, the branch was in this
> > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > .31 didn't result in a better .32, and even the final .33 had
> its own
> > issues.
> >
> > This would have been precisely the same outcome between RC1
> > and RC4, if the project doesn't keep the branch stable for even the
> > week or months required to craft a successful release, and if that
> > occurs on 2.4.x branch, that is an interruption of effort towards
> > release n+1, frustrating contributors.
> >
> > Note we don't publish anything not approved by the PMC, so
> > there would be the same "vote" to release an RC.
> >
> > Net <-> net, this is the status quo which failed us so badly this
> > past winter (now with alphabetic characters!)
> >
> >
> > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
> >> The idea is encouraging and fostering a broader test audience.
> >>
> >>
> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr
> <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> >>
> >> Unless I misunderstand...
> >>
> >> 2.4.30-RC1 (rejected)
> >> 2.4.30-RC2 (our .31, rejected)
> >> 2.4.30-RC3 (our .32, rejected)
> >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> >>
> >> With all the associated changes in between, no actual change in
> branch
> >> management, scope, feature creep, etc?
> >>
> >> This sounds like dressing up the status quo with different labels.
> >>
> >>
> >>
> >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
> >>>
> >>>
> >>>
> >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr
> <wrowe@rowe-clan.net <ma...@rowe-clan.net>>
> >>> > wrote:
> >>> >
> >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski
> <jim@jagunet.com <ma...@jagunet.com>> wrote:
> >>> >> With all this in mind, should we try to set things up so
> that the
> >>> >> next release cycle uses the concept of RCs?
> >>> >>
> >>> >> If so, and if people like, I can come up with a baseline
> >>> >> proposal on the process for us to debate and come to
> >>> >> some consensus on.
> >>> >
> >>> > Would you define an RC? What changes are allowable in that
> branch?
> >>>
> >>>
> >>> The idea is that right now we take an existing state in SVN
> >>> and tag it as, for example, 2.4.121. We then vote on that tag
> >>> and the artifacts released from that tag. No work is done on
> >>> the 2.4 branch while testing is done so that we ensure that
> >>> the SVN rev on branch == the one for the tag
> >>
> >>
> >> Not necessary to freeze; a tag can always be applied to an
> older rev.
> >>
> >>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> >>> vote does not pass, we continue on the 2.4 branch, fix the
> >>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
> >>>
> >>> If the vote does pass we tag the branch, which is still == RC#
> >>> at this stage, as 2.4.121 (ap_release.h mods included). We
> >>> still even at this stage test and vote on the release as we have
> >>> for decades. If it passes, we release. If not, for some reason,
> >>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> >>> the above.
> >>>
> >>> This is the overall idea... more flesh to be added.
> >>
> >>
>
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I don't disagree with RC's entirely, or the mechanism you suggest, but that
isn't what I read as proposed.
Our issue is that every httpd must be distinguished, we won't ship four
tarballs all claiming 2.4.34 (GA). Which one is the person complaining
about? Are we back to SHA signature of the source tarball (that isn't even
assuredly what they built the binary from?)
We can decorate the rc in the versioning, but that isn't part of 2.4.x API,
unless we swap out the "-dev" string tag for an "-rc#" value.
It is not reasonable to lock a branch for an indeterminate length of time.
Branching the RC into what becomes the final release, and making it painful
to backport first to 2.4.x and finally 2.4.n-rc branch might help
discourage disruptive backports, but there is no suggestion yet of what is
acceptable, either on such a frozen main branch or rc branch.
In fact our policy reflects that two competing release candidates is an
entire valid and even expected situation, and any process that further
blocks this should be firmly rebuffed.
As it reads so far the proposal is the way we do things, now conserving
subversion numbers as precious, if only to reenforce a stake in the ground
that version major and minor numbers are similarly precious, (which they
are not.)
With the addition of freezing changes on 2.4.x branch for a time we succeed
in impeading progress towards version .next, while not otherwise changing
the status quo.
What you suggest is yet another thing, based on forking the RC release
branch, and I haven't seen that accepted by the committee yet.
On Thu, Apr 19, 2018, 16:43 David Zuelke <dz...@salesforce.com> wrote:
> The main difference is that you have a release branch in which fixes
> to bugs or regressions found during 2.4.x RCs can be made, while work
> on 2.4.(x+1) can continue in the main 2.4 branch.
>
> Another benefit is that people who do automated builds (e.g. me) can
> grep for "RC" in the version number and have it fetch from
> https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
> The changelogs are more readable as well, because it's obvious which
> intermediary RC releases belong together. If you look at
> https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> indication that e.g. 2.4.31 was never released.
>
>
> On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > What possible improvement occurs if there is no branch discipline
> > on 2.4.x development? We just echoed effectively your proposal,
> > using numbers rather than RC designations, and still .33 has this
> > host of issues. With no release since .29, the branch was in this
> > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > .31 didn't result in a better .32, and even the final .33 had its own
> > issues.
> >
> > This would have been precisely the same outcome between RC1
> > and RC4, if the project doesn't keep the branch stable for even the
> > week or months required to craft a successful release, and if that
> > occurs on 2.4.x branch, that is an interruption of effort towards
> > release n+1, frustrating contributors.
> >
> > Note we don't publish anything not approved by the PMC, so
> > there would be the same "vote" to release an RC.
> >
> > Net <-> net, this is the status quo which failed us so badly this
> > past winter (now with alphabetic characters!)
> >
> >
> > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >> The idea is encouraging and fostering a broader test audience.
> >>
> >>
> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >>
> >> Unless I misunderstand...
> >>
> >> 2.4.30-RC1 (rejected)
> >> 2.4.30-RC2 (our .31, rejected)
> >> 2.4.30-RC3 (our .32, rejected)
> >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> >>
> >> With all the associated changes in between, no actual change in branch
> >> management, scope, feature creep, etc?
> >>
> >> This sounds like dressing up the status quo with different labels.
> >>
> >>
> >>
> >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <ji...@jagunet.com> wrote:
> >>>
> >>>
> >>>
> >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wrowe@rowe-clan.net
> >
> >>> > wrote:
> >>> >
> >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com>
> wrote:
> >>> >> With all this in mind, should we try to set things up so that the
> >>> >> next release cycle uses the concept of RCs?
> >>> >>
> >>> >> If so, and if people like, I can come up with a baseline
> >>> >> proposal on the process for us to debate and come to
> >>> >> some consensus on.
> >>> >
> >>> > Would you define an RC? What changes are allowable in that branch?
> >>>
> >>>
> >>> The idea is that right now we take an existing state in SVN
> >>> and tag it as, for example, 2.4.121. We then vote on that tag
> >>> and the artifacts released from that tag. No work is done on
> >>> the 2.4 branch while testing is done so that we ensure that
> >>> the SVN rev on branch == the one for the tag
> >>
> >>
> >> Not necessary to freeze; a tag can always be applied to an older rev.
> >>
> >>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> >>> vote does not pass, we continue on the 2.4 branch, fix the
> >>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
> >>>
> >>> If the vote does pass we tag the branch, which is still == RC#
> >>> at this stage, as 2.4.121 (ap_release.h mods included). We
> >>> still even at this stage test and vote on the release as we have
> >>> for decades. If it passes, we release. If not, for some reason,
> >>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> >>> the above.
> >>>
> >>> This is the overall idea... more flesh to be added.
> >>
> >>
>
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by David Zuelke <dz...@salesforce.com>.
The main difference is that you have a release branch in which fixes
to bugs or regressions found during 2.4.x RCs can be made, while work
on 2.4.(x+1) can continue in the main 2.4 branch.
Another benefit is that people who do automated builds (e.g. me) can
grep for "RC" in the version number and have it fetch from
https://dist.apache.org/repos/dist/dev/httpd/ instead.
The changelogs are more readable as well, because it's obvious which
intermediary RC releases belong together. If you look at
https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
indication that e.g. 2.4.31 was never released.
On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> What possible improvement occurs if there is no branch discipline
> on 2.4.x development? We just echoed effectively your proposal,
> using numbers rather than RC designations, and still .33 has this
> host of issues. With no release since .29, the branch was in this
> continuous state of flux between 2.4.30 and 2.4.33. Testing the
> 2.4.30 release did not result in a better, eventual 2.4.31, testing
> .31 didn't result in a better .32, and even the final .33 had its own
> issues.
>
> This would have been precisely the same outcome between RC1
> and RC4, if the project doesn't keep the branch stable for even the
> week or months required to craft a successful release, and if that
> occurs on 2.4.x branch, that is an interruption of effort towards
> release n+1, frustrating contributors.
>
> Note we don't publish anything not approved by the PMC, so
> there would be the same "vote" to release an RC.
>
> Net <-> net, this is the status quo which failed us so badly this
> past winter (now with alphabetic characters!)
>
>
> On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> The idea is encouraging and fostering a broader test audience.
>>
>>
>> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> Unless I misunderstand...
>>
>> 2.4.30-RC1 (rejected)
>> 2.4.30-RC2 (our .31, rejected)
>> 2.4.30-RC3 (our .32, rejected)
>> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>>
>> With all the associated changes in between, no actual change in branch
>> management, scope, feature creep, etc?
>>
>> This sounds like dressing up the status quo with different labels.
>>
>>
>>
>> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>>
>>>
>>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net>
>>> > wrote:
>>> >
>>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> >> With all this in mind, should we try to set things up so that the
>>> >> next release cycle uses the concept of RCs?
>>> >>
>>> >> If so, and if people like, I can come up with a baseline
>>> >> proposal on the process for us to debate and come to
>>> >> some consensus on.
>>> >
>>> > Would you define an RC? What changes are allowable in that branch?
>>>
>>>
>>> The idea is that right now we take an existing state in SVN
>>> and tag it as, for example, 2.4.121. We then vote on that tag
>>> and the artifacts released from that tag. No work is done on
>>> the 2.4 branch while testing is done so that we ensure that
>>> the SVN rev on branch == the one for the tag
>>
>>
>> Not necessary to freeze; a tag can always be applied to an older rev.
>>
>>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>>> vote does not pass, we continue on the 2.4 branch, fix the
>>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>>
>>> If the vote does pass we tag the branch, which is still == RC#
>>> at this stage, as 2.4.121 (ap_release.h mods included). We
>>> still even at this stage test and vote on the release as we have
>>> for decades. If it passes, we release. If not, for some reason,
>>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>>> the above.
>>>
>>> This is the overall idea... more flesh to be added.
>>
>>
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
What possible improvement occurs if there is no branch discipline
on 2.4.x development? We just echoed effectively your proposal,
using numbers rather than RC designations, and still .33 has this
host of issues. With no release since .29, the branch was in this
continuous state of flux between 2.4.30 and 2.4.33. Testing the
2.4.30 release did not result in a better, eventual 2.4.31, testing
.31 didn't result in a better .32, and even the final .33 had its own
issues.
This would have been precisely the same outcome between RC1
and RC4, if the project doesn't keep the branch stable for even the
week or months required to craft a successful release, and if that
occurs on 2.4.x branch, that is an interruption of effort towards
release n+1, frustrating contributors.
Note we don't publish anything not approved by the PMC, so
there would be the same "vote" to release an RC.
Net <-> net, this is the status quo which failed us so badly this
past winter (now with alphabetic characters!)
On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> The idea is encouraging and fostering a broader test audience.
>
>
> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Unless I misunderstand...
>
> 2.4.30-RC1 (rejected)
> 2.4.30-RC2 (our .31, rejected)
> 2.4.30-RC3 (our .32, rejected)
> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>
> With all the associated changes in between, no actual change in branch
> management, scope, feature creep, etc?
>
> This sounds like dressing up the status quo with different labels.
>
>
>
> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>
>>
>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net>
>> > wrote:
>> >
>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> >> With all this in mind, should we try to set things up so that the
>> >> next release cycle uses the concept of RCs?
>> >>
>> >> If so, and if people like, I can come up with a baseline
>> >> proposal on the process for us to debate and come to
>> >> some consensus on.
>> >
>> > Would you define an RC? What changes are allowable in that branch?
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag
>
>
> Not necessary to freeze; a tag can always be applied to an older rev.
>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Jim Jagielski <ji...@jaguNET.com>.
The idea is encouraging and fostering a broader test audience.
> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Unless I misunderstand...
>
> 2.4.30-RC1 (rejected)
> 2.4.30-RC2 (our .31, rejected)
> 2.4.30-RC3 (our .32, rejected)
> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>
> With all the associated changes in between, no actual change in branch management, scope, feature creep, etc?
>
> This sounds like dressing up the status quo with different labels.
>
>
>
> On Thu, Apr 19, 2018, 10:37 Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>
>
> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> >
> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
> >> With all this in mind, should we try to set things up so that the
> >> next release cycle uses the concept of RCs?
> >>
> >> If so, and if people like, I can come up with a baseline
> >> proposal on the process for us to debate and come to
> >> some consensus on.
> >
> > Would you define an RC? What changes are allowable in that branch?
>
>
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag
>
> Not necessary to freeze; a tag can always be applied to an older rev.
>
> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
>
> This is the overall idea... more flesh to be added.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Unless I misunderstand...
2.4.30-RC1 (rejected)
2.4.30-RC2 (our .31, rejected)
2.4.30-RC3 (our .32, rejected)
2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
With all the associated changes in between, no actual change in branch
management, scope, feature creep, etc?
This sounds like dressing up the status quo with different labels.
On Thu, Apr 19, 2018, 10:37 Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >> With all this in mind, should we try to set things up so that the
> >> next release cycle uses the concept of RCs?
> >>
> >> If so, and if people like, I can come up with a baseline
> >> proposal on the process for us to debate and come to
> >> some consensus on.
> >
> > Would you define an RC? What changes are allowable in that branch?
>
>
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag
>
Not necessary to freeze; a tag can always be applied to an older rev.
Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
>
> This is the overall idea... more flesh to be added.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/19/2018 09:19 PM, Rainer Jung wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>
>>
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>
>>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>> With all this in mind, should we try to set things up so that the
>>>> next release cycle uses the concept of RCs?
>>>>
>>>> If so, and if people like, I can come up with a baseline
>>>> proposal on the process for us to debate and come to
>>>> some consensus on.
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
> IMHO we should aim at keeping the RC phase as stable as possible and focuse on the code from which we tagged RC1 and
> which we actually want to release. So after RC1 there should be only fixes for regressions, no other fixes or backports.
>
> Other projects for example branch at the start of the release process (using your version example 2.4.121 here):
>
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
> - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version adjustments
> - do final release vote
+1. Sounds reasonable, gives more time for testing avoids freezes on the 2.4.x branch while keeping the RC stable. Let's
try this and see the results.
Regards
Rüdiger
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by David Zuelke <dz...@salesforce.com>.
Yup, that's exactly it. Have a release branch, iterate there, and in
the meantime, work in the version series branch can continue. That
brings one huge benefit over the current model already: no freezes
necessary, no potential additional breaks after a "burned" version.
On Thu, Apr 19, 2018 at 9:19 PM, Rainer Jung <ra...@kippdata.de> wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>
>>
>>
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net>
>>> wrote:
>>>
>>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>>
>>>> With all this in mind, should we try to set things up so that the
>>>> next release cycle uses the concept of RCs?
>>>>
>>>> If so, and if people like, I can come up with a baseline
>>>> proposal on the process for us to debate and come to
>>>> some consensus on.
>>>
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>
> IMHO we should aim at keeping the RC phase as stable as possible and focuse
> on the code from which we tagged RC1 and which we actually want to release.
> So after RC1 there should be only fixes for regressions, no other fixes or
> backports.
>
> Other projects for example branch at the start of the release process (using
> your version example 2.4.121 here):
>
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
> - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version
> adjustments
> - do final release vote
>
> While we are doing RCs backport and other fixing work could proceed on the
> 2.4.x branch, because the RCs are created from the version branch.
>
> ... 2c ...
>
> Rainer
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>
>
>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> With all this in mind, should we try to set things up so that the
>>> next release cycle uses the concept of RCs?
>>>
>>> If so, and if people like, I can come up with a baseline
>>> proposal on the process for us to debate and come to
>>> some consensus on.
>>
>> Would you define an RC? What changes are allowable in that branch?
>
>
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag.
>
> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
>
> This is the overall idea... more flesh to be added.
IMHO we should aim at keeping the RC phase as stable as possible and
focuse on the code from which we tagged RC1 and which we actually want
to release. So after RC1 there should be only fixes for regressions, no
other fixes or backports.
Other projects for example branch at the start of the release process
(using your version example 2.4.121 here):
- branch 2.4.x as a 2.4.121 branch
- tag 2.4.121-RC1 on that branch
- allow for a week or two (?) of public testing
- fix incoming regressions
- patches go via trunk to 2.4.x to 2.4.121 branch
- cut new RCs if previous RC needed fixes
- create final release tag from last RC plus some script driven version
adjustments
- do final release vote
While we are doing RCs backport and other fixing work could proceed on
the 2.4.x branch, because the RCs are created from the version branch.
... 2c ...
Rainer
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> With all this in mind, should we try to set things up so that the
>> next release cycle uses the concept of RCs?
>>
>> If so, and if people like, I can come up with a baseline
>> proposal on the process for us to debate and come to
>> some consensus on.
>
> Would you define an RC? What changes are allowable in that branch?
The idea is that right now we take an existing state in SVN
and tag it as, for example, 2.4.121. We then vote on that tag
and the artifacts released from that tag. No work is done on
the 2.4 branch while testing is done so that we ensure that
the SVN rev on branch == the one for the tag.
Instead, we tag at 2.4.121-RC1. We do the exact same. If the
vote does not pass, we continue on the 2.4 branch, fix the
issues, and then tag a 2.4.121-RC2. Rinse and repeat.
If the vote does pass we tag the branch, which is still == RC#
at this stage, as 2.4.121 (ap_release.h mods included). We
still even at this stage test and vote on the release as we have
for decades. If it passes, we release. If not, for some reason,
we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
the above.
This is the overall idea... more flesh to be added.
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> With all this in mind, should we try to set things up so that the
> next release cycle uses the concept of RCs?
>
> If so, and if people like, I can come up with a baseline
> proposal on the process for us to debate and come to
> some consensus on.
Would you define an RC? What changes are allowable in that branch?
Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS:
Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Graham Leggett <mi...@sharp.fm>.
On 19 Apr 2018, at 5:11 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> With all this in mind, should we try to set things up so that the
> next release cycle uses the concept of RCs?
>
> If so, and if people like, I can come up with a baseline
> proposal on the process for us to debate and come to
> some consensus on.
What specific problem does this aim to solve?
Regards,
Graham
—
Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re:
Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])
Posted by Jim Jagielski <ji...@jaguNET.com>.
With all this in mind, should we try to set things up so that the
next release cycle uses the concept of RCs?
If so, and if people like, I can come up with a baseline
proposal on the process for us to debate and come to
some consensus on.
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 19, 2018 at 10:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> and BFDL/NIH-tier levels of "we don't do that, we do things this way... my way or the highway."
>
> That is not quite true nor fair.
>
> It does not take a BFDL/NIH-er, for example, to say "We don't
> release s/w under the GPLv3", nor if someone sez that, does
> that make them a BDFL. Nor does anyone have the ability
> to have anything like "my way or the highway" even stick.
We aren't discussing GPLv3 or any other ASF-wide policy here.
We are discussing how the HTTP Server project versions and
releases software for the public good. There are dozens of ways
we can accomplish that, all of which fit into ASF policy.
We operate by consensus. Which means, if any PMC member
is unwilling to accept change to our release or versioning, we are
stuck with status quo. Any time the argument against a change
becomes "that isn't how we have done it", the argument needs
to be judged by the success of that status quo.
This entire thread is predicated with my belief that the status quo
processes, not the code base or committers, has problems. All
the proposals made in previous threads on the subject were shouted
down, and the project release management, measured in bugs
and regressions, still suffers all the same issues as it has for a
number of years.
Could you be kind enough to point out where you have proposed
or accepted a change to the release process that we can use as
a starting point of a dialog? We are obviously not talking past
one another anymore that the process stands to be improved.
Since you have objected to each of my prior proposals (and all
those presented by others), I'd like to find out if we can converge
on one of your proposals?
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> and BFDL/NIH-tier levels of "we don't do that, we do things this way... my way or the highway."
>
That is not quite true nor fair.
It does not take a BFDL/NIH-er, for example, to say "We don't
release s/w under the GPLv3", nor if someone sez that, does
that make them a BDFL. Nor does anyone have the ability
to have anything like "my way or the highway" even stick.
People can say it, sure, but I don't think anyone has,
unless, of course, in cases like the GPLv3 example above,
but then, obviously, it's not "my/their" way at all. It
is *our* way.
Please don't make this personal.
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 19, 2018, 09:32 Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> > On Apr 19, 2018, at 10:20 AM, Stefan Eissing <
> stefan.eissing@greenbytes.de> wrote:
> >
> > Frankly, I think the current state of things does not work well. It
> seems folly to say we should change nothing, only have more stable releases.
>
> No one is saying we change *nothing*. There just seems to be disagreement
> that what we should change is from "release when it's ready" to "release
> when the calendar sez
>
No suggested changes have met with acceptance, other than "more tests" and
some undefined "more frequent" releases.
I have several years of threads to dev@ of your's and a couple other's
objections to every substantive change proposed to the underlying process
by myself and others. All offered to achieve more consistent results for
our users to count on. Generally with the rationals of "that wouldn't be
fun" or "that isn't the ASF spirit" and BFDL/NIH-tier levels of "we don't
do that, we do things this way... my way or the highway."
That's why I introduced the subject differently, no perscriptions. What
would you suggest we *change* that would be fun/make people happy/produce
"the best available version of httpd" on a regular basis? I'm 100% with
Stefan, changing nothing except expectations of "doing better" is pure
folly.
While it is great we have fun, that can't continue at the expense of
other's enjoyment, and the expense of perpetually broken "stable" releases.
>
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 19, 2018, at 10:20 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> Frankly, I think the current state of things does not work well. It seems folly to say we should change nothing, only have more stable releases.
No one is saying we change *nothing*. There just seems to be disagreement that what we should change is from "release when it's ready" to "release when the calendar sez"
Re: AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Stefan Eissing <st...@greenbytes.de>.
Frankly, I think the current state of things does not work well. It seems folly to say we should change nothing, only have more stable releases.
Our current approach gave us around 6 months of „ship when it‘s ready“ and the quality is not what we want - as expressed by Jim, Bill and others.
Why a regular 2.4 release is in conflict with „ship when it‘s ready“ I do not understand. Surely, we only backport when it‘s ready? Where is this connected?
> Am 19.04.2018 um 15:41 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>
> I am also more in the "ship when it is ready", then "ship when it is time" boat.
> We probably could have some automated "nightlyies" which are not releases in the ASF sense (as release requires voting),
> but only some sort of convenience transformation of an svn export / co that creates a tar ball.
> But this only creates value if a broader audience tests them.
> But I guess most people that benefit from this easier processing of "nightlyies" would only test them when they see that
> something interesting is contained for them.
> Which brings us back to "ship when its ready". OTOH " nightlyies" would add testers that have different / their own
> criteria's on "when it is ready"
>
> Regards
>
> Rüdiger
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jim Jagielski <ji...@jaguNET.com>
>> Gesendet: Donnerstag, 19. April 2018 15:06
>> An: dev@httpd.apache.org
>> Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit
>> Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
>>
>> One of the great things about working on open source is that
>> one is NOT burdened by schedules. That releases are done
>> "when ready" not when some artificial schedule or some
>> calendar date demands. Changing this mindset on httpd would
>> be an extremely major change, IMO, from what's been at its
>> heart since 1995. Some may say that that is a good thing,
>> that we need to "get inline with the times"... I would disagree,
>> especially if we still want to encourage new contributions,
>> new contributors and new (volunteer) committers.
>>
>> I submit that "doing a release" is not one of the problems that should
>> be a priority to "fix".
>>
>>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing
>> <st...@greenbytes.de> wrote:
>>>
>>> Daniel,
>>>
>>> would you find it feasible to make a 2.4 release every first Tuesday
>> of the month? Other projects have excellent experiences with such
>> release timings.
>>>
>>> I‘d expect this would let us focus on the changes („one more week
>> until release“), take off pressure („we can do it in the next release“),
>> avoid meta discussions („is this a good time?“) and let us streamline
>> the test/release work with changes in process/automation with a higher
>> motivation.
>>>
>>> Again, this would be your burden and call until we have so much
>> routine/automation that everyone can do it. So it needs to be your
>> decision.
>>>
>>> Cheers, Stefan
>>>
>>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
>>>>
>>>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>>>>> The release cycle is hours, to the benefit of all interested. Be it
>> a blocking bug fixed or a nice feature implemented. These are mostly
>> people who do it for fun. Some even run large server clusters, so a
>> „hobbyist“ label does not apply.
>>>>> Hours, yes, but we've had a willing RM, who has automated even
>>>>> more of this than Jim or I had, and has a very hard time finding
>>>>> any target to point to. E.g. "ok, that looks like the right
>> resolution
>>>>> to the last of the regressions... let's..." ... "...oh there are all
>> these
>>>>> other shiny objects in STATUS... rock-n-roll!!!"
>>>>> ...
>>>>
>>>> What's particularly interesting to me, as I follow the conversation
>> in
>>>> my usual lurker-mode, is that Bill hit the nail on the head with this
>>>> observation. I was waiting for the dust to settle to run through the
>>>> scripts again for another T&R and release vote... but am not totally
>>>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>>>> the merging discussion so instead started parsing for "Yep. We're
>> good
>>>> now.")
>>>>
>>>> My current read on the conversation is that we're happy (or maybe
>> just
>>>> content) with the SSL merging fixes and we should prep to ship 2.4.34
>> as
>>>> a fix. Does anyone disagree?
>>>>
>>>> --
>>>> Daniel Ruggeri
>>>>
>>>
>
AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
I am also more in the "ship when it is ready", then "ship when it is time" boat.
We probably could have some automated "nightlyies" which are not releases in the ASF sense (as release requires voting),
but only some sort of convenience transformation of an svn export / co that creates a tar ball.
But this only creates value if a broader audience tests them.
But I guess most people that benefit from this easier processing of "nightlyies" would only test them when they see that
something interesting is contained for them.
Which brings us back to "ship when its ready". OTOH " nightlyies" would add testers that have different / their own
criteria's on "when it is ready"
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski <ji...@jaguNET.com>
> Gesendet: Donnerstag, 19. April 2018 15:06
> An: dev@httpd.apache.org
> Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit
> Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
>
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
>
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
>
> > On Apr 19, 2018, at 1:24 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
> >
> > Daniel,
> >
> > would you find it feasible to make a 2.4 release every first Tuesday
> of the month? Other projects have excellent experiences with such
> release timings.
> >
> > I‘d expect this would let us focus on the changes („one more week
> until release“), take off pressure („we can do it in the next release“),
> avoid meta discussions („is this a good time?“) and let us streamline
> the test/release work with changes in process/automation with a higher
> motivation.
> >
> > Again, this would be your burden and call until we have so much
> routine/automation that everyone can do it. So it needs to be your
> decision.
> >
> > Cheers, Stefan
> >
> >> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
> >>
> >> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
> >>>> The release cycle is hours, to the benefit of all interested. Be it
> a blocking bug fixed or a nice feature implemented. These are mostly
> people who do it for fun. Some even run large server clusters, so a
> „hobbyist“ label does not apply.
> >>> Hours, yes, but we've had a willing RM, who has automated even
> >>> more of this than Jim or I had, and has a very hard time finding
> >>> any target to point to. E.g. "ok, that looks like the right
> resolution
> >>> to the last of the regressions... let's..." ... "...oh there are all
> these
> >>> other shiny objects in STATUS... rock-n-roll!!!"
> >>> ...
> >>
> >> What's particularly interesting to me, as I follow the conversation
> in
> >> my usual lurker-mode, is that Bill hit the nail on the head with this
> >> observation. I was waiting for the dust to settle to run through the
> >> scripts again for another T&R and release vote... but am not totally
> >> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> >> the merging discussion so instead started parsing for "Yep. We're
> good
> >> now.")
> >>
> >> My current read on the conversation is that we're happy (or maybe
> just
> >> content) with the SSL merging fixes and we should prep to ship 2.4.34
> as
> >> a fix. Does anyone disagree?
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Luca Toscano <to...@gmail.com>.
2018-04-19 15:40 GMT+02:00 Eric Covener <co...@gmail.com>:
> On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> > I agree a case could be made for considering adding an RC stage
> > to our release process... it would require some additional tooling
> > and some sort of additions to ap_release.h but nothing insurmountable.
> >
> > That might be a nice small-and-easily-reversable step to address
> > some of the issues that we've been having lately.
>
> Including burning version numbers!
>
+1
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Eric Covener <co...@gmail.com>.
On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I agree a case could be made for considering adding an RC stage
> to our release process... it would require some additional tooling
> and some sort of additions to ap_release.h but nothing insurmountable.
>
> That might be a nice small-and-easily-reversable step to address
> some of the issues that we've been having lately.
Including burning version numbers!
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Jim Jagielski <ji...@jaguNET.com>.
I agree a case could be made for considering adding an RC stage
to our release process... it would require some additional tooling
and some sort of additions to ap_release.h but nothing insurmountable.
That might be a nice small-and-easily-reversable step to address
some of the issues that we've been having lately.
> On Apr 19, 2018, at 9:25 AM, Steffen <in...@apachelounge.com> wrote:
>
> ++1
>
> The current versioning and times are fine for me. Only the vote time is too short. At Apachelounge I have once in a while RC’s from branches before voting, so the community had more time to test. Issues are then earlier discovered.
>
> Distributors are free to have a RC any time when they think, looking at changes in branches, it helps.
>
>> Op 19 apr. 2018 om 15:06 heeft Jim Jagielski <ji...@jaguNET.com> het volgende geschreven:
>>
>> One of the great things about working on open source is that
>> one is NOT burdened by schedules. That releases are done
>> "when ready" not when some artificial schedule or some
>> calendar date demands. Changing this mindset on httpd would
>> be an extremely major change, IMO, from what's been at its
>> heart since 1995. Some may say that that is a good thing,
>> that we need to "get inline with the times"... I would disagree,
>> especially if we still want to encourage new contributions,
>> new contributors and new (volunteer) committers.
>>
>> I submit that "doing a release" is not one of the problems that should
>> be a priority to "fix".
>>
>>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>>>
>>> Daniel,
>>>
>>> would you find it feasible to make a 2.4 release every first Tuesday of the month? Other projects have excellent experiences with such release timings.
>>>
>>> I‘d expect this would let us focus on the changes („one more week until release“), take off pressure („we can do it in the next release“), avoid meta discussions („is this a good time?“) and let us streamline the test/release work with changes in process/automation with a higher motivation.
>>>
>>> Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
>>>
>>> Cheers, Stefan
>>>
>>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
>>>>
>>>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>>>>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
>>>>> Hours, yes, but we've had a willing RM, who has automated even
>>>>> more of this than Jim or I had, and has a very hard time finding
>>>>> any target to point to. E.g. "ok, that looks like the right resolution
>>>>> to the last of the regressions... let's..." ... "...oh there are all these
>>>>> other shiny objects in STATUS... rock-n-roll!!!"
>>>>> ...
>>>>
>>>> What's particularly interesting to me, as I follow the conversation in
>>>> my usual lurker-mode, is that Bill hit the nail on the head with this
>>>> observation. I was waiting for the dust to settle to run through the
>>>> scripts again for another T&R and release vote... but am not totally
>>>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>>>> the merging discussion so instead started parsing for "Yep. We're good
>>>> now.")
>>>>
>>>> My current read on the conversation is that we're happy (or maybe just
>>>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>>>> a fix. Does anyone disagree?
>>>>
>>>> --
>>>> Daniel Ruggeri
>>>>
>>>
>>
>
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Steffen <in...@apachelounge.com>.
++1
The current versioning and times are fine for me. Only the vote time is too short. At Apachelounge I have once in a while RC’s from branches before voting, so the community had more time to test. Issues are then earlier discovered.
Distributors are free to have a RC any time when they think, looking at changes in branches, it helps.
> Op 19 apr. 2018 om 15:06 heeft Jim Jagielski <ji...@jaguNET.com> het volgende geschreven:
>
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
>
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
>
>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>>
>> Daniel,
>>
>> would you find it feasible to make a 2.4 release every first Tuesday of the month? Other projects have excellent experiences with such release timings.
>>
>> I‘d expect this would let us focus on the changes („one more week until release“), take off pressure („we can do it in the next release“), avoid meta discussions („is this a good time?“) and let us streamline the test/release work with changes in process/automation with a higher motivation.
>>
>> Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
>>
>> Cheers, Stefan
>>
>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
>>>
>>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>>>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
>>>> Hours, yes, but we've had a willing RM, who has automated even
>>>> more of this than Jim or I had, and has a very hard time finding
>>>> any target to point to. E.g. "ok, that looks like the right resolution
>>>> to the last of the regressions... let's..." ... "...oh there are all these
>>>> other shiny objects in STATUS... rock-n-roll!!!"
>>>> ...
>>>
>>> What's particularly interesting to me, as I follow the conversation in
>>> my usual lurker-mode, is that Bill hit the nail on the head with this
>>> observation. I was waiting for the dust to settle to run through the
>>> scripts again for another T&R and release vote... but am not totally
>>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>>> the merging discussion so instead started parsing for "Yep. We're good
>>> now.")
>>>
>>> My current read on the conversation is that we're happy (or maybe just
>>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>>> a fix. Does anyone disagree?
>>>
>>> --
>>> Daniel Ruggeri
>>>
>>
>
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Jim Jagielski <ji...@jaguNET.com>.
One of the great things about working on open source is that
one is NOT burdened by schedules. That releases are done
"when ready" not when some artificial schedule or some
calendar date demands. Changing this mindset on httpd would
be an extremely major change, IMO, from what's been at its
heart since 1995. Some may say that that is a good thing,
that we need to "get inline with the times"... I would disagree,
especially if we still want to encourage new contributions,
new contributors and new (volunteer) committers.
I submit that "doing a release" is not one of the problems that should
be a priority to "fix".
> On Apr 19, 2018, at 1:24 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> Daniel,
>
> would you find it feasible to make a 2.4 release every first Tuesday of the month? Other projects have excellent experiences with such release timings.
>
> I‘d expect this would let us focus on the changes („one more week until release“), take off pressure („we can do it in the next release“), avoid meta discussions („is this a good time?“) and let us streamline the test/release work with changes in process/automation with a higher motivation.
>
> Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
>
> Cheers, Stefan
>
>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
>>
>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
>>> Hours, yes, but we've had a willing RM, who has automated even
>>> more of this than Jim or I had, and has a very hard time finding
>>> any target to point to. E.g. "ok, that looks like the right resolution
>>> to the last of the regressions... let's..." ... "...oh there are all these
>>> other shiny objects in STATUS... rock-n-roll!!!"
>>> ...
>>
>> What's particularly interesting to me, as I follow the conversation in
>> my usual lurker-mode, is that Bill hit the nail on the head with this
>> observation. I was waiting for the dust to settle to run through the
>> scripts again for another T&R and release vote... but am not totally
>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>> the merging discussion so instead started parsing for "Yep. We're good
>> now.")
>>
>> My current read on the conversation is that we're happy (or maybe just
>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>> a fix. Does anyone disagree?
>>
>> --
>> Daniel Ruggeri
>>
>
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Apr 20, 2018 at 2:36 AM, Rainer Jung <ra...@kippdata.de> wrote:
>
>> The necessity/evaluation of the dependency belongs
>> here... we once could compile httpd 2.4 against APR 1.4 family and had
>> agreement that this would continue through the lifecycle, but I seriously
>> doubt that is still true today.
>
> If that is a concern, it would be better to check and if needed start an
> independent discussion thread for that.
The logic I pointed Jeff at has four orientations, stable, candidate, snapshot
and bleed (for future revs, e.g. trunk/ across the board.)
What oss-httpd-build doesn't do (at least not yet) are all the permutations
of very old components, e.g. APR gen 1.4.x + httpd. I don't have enough
cycles to tackle it all, but as the Makefile.checkout phase is enhanced,
that's one really interesting aspect to consider (1.4.x gen, 1.5.x gen, the
current 1.6.x gen and eventually 1.7.x APR.)
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Rainer Jung <ra...@kippdata.de>.
Am 20.04.2018 um 09:22 schrieb William A Rowe Jr:
> On Fri, Apr 20, 2018 at 2:15 AM, Rainer Jung <ra...@kippdata.de> wrote:
>> Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES:
>>
>> *) poll, port: re-add the wakeup pipe to the pollset after it triggered.
>> Not doing this occasionally lead to httpd event MPM processes hanging
>> during process shutdown. PR 61786. [Yann Ylavic]
>
> That's an interesting question, would you propose a release to the APR
> developer's list?
I will, but I wanted to first check this from the point of view of hte
httpd project as a consumer of APR/APU and as a topic that might
influence release timing.
> The necessity/evaluation of the dependency belongs
> here... we once could compile httpd 2.4 against APR 1.4 family and had
> agreement that this would continue through the lifecycle, but I seriously
> doubt that is still true today.
If that is a concern, it would be better to check and if needed start an
independent discussion thread for that.
Regards,
Rainer
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Apr 20, 2018 at 2:15 AM, Rainer Jung <ra...@kippdata.de> wrote:
> Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES:
>
> *) poll, port: re-add the wakeup pipe to the pollset after it triggered.
> Not doing this occasionally lead to httpd event MPM processes hanging
> during process shutdown. PR 61786. [Yann Ylavic]
That's an interesting question, would you propose a release to the APR
developer's list? The necessity/evaluation of the dependency belongs
here... we once could compile httpd 2.4 against APR 1.4 family and had
agreement that this would continue through the lifecycle, but I seriously
doubt that is still true today.
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Rainer Jung <ra...@kippdata.de>.
Am 20.04.2018 um 11:39 schrieb Eric Covener:
> On Fri, Apr 20, 2018 at 3:15 AM, Rainer Jung <ra...@kippdata.de> wrote:
>> Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES:
>>
>> *) poll, port: re-add the wakeup pipe to the pollset after it triggered.
>> Not doing this occasionally lead to httpd event MPM processes hanging
>> during process shutdown. PR 61786. [Yann Ylavic]
>
>
> Never hurts, but it is just Solaris isn't it?
I think so for the CHANGES topic (ports impl of poll), although there
were more changes in the backport commit for which I'm not sure about
how important they are and when they apply.
Regards,
Rainer
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Eric Covener <co...@gmail.com>.
On Fri, Apr 20, 2018 at 3:15 AM, Rainer Jung <ra...@kippdata.de> wrote:
> Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES:
>
> *) poll, port: re-add the wakeup pipe to the pollset after it triggered.
> Not doing this occasionally lead to httpd event MPM processes hanging
> during process shutdown. PR 61786. [Yann Ylavic]
Never hurts, but it is just Solaris isn't it?
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Rainer Jung <ra...@kippdata.de>.
Do we need a quick APR 1.6.4 to pick up r1819938? From CHANGES:
*) poll, port: re-add the wakeup pipe to the pollset after it triggered.
Not doing this occasionally lead to httpd event MPM processes hanging
during process shutdown. PR 61786. [Yann Ylavic]
From the commit log:
====================================================================
Merge r1819857, r1819858, r1819860, r1819861, r1819934, r1819935 from trunk:
testpoll: check that the wakeup pipe is still in the pollset after
returning from poll(), e.g. APR_POLLSET_PORT should re-arm it automatically.
poll, port: re-add the wakeup pipe to the pollset after it triggered.
Just like user fds (file, socket), otherwise it's one shot only (PR-61786).
Corresponding test committed in r1819857.
poll, port: no need to release and re-acquire the lock in between
walking the pollset and handling the dead ring, all is
simple/fast/nonblocking ops.
Also, set types of "i" and "j" respectively to the ones of nget and *num.
poll, port: follow up to r1819860.
This test is redundant now, axe it (no functional change).
poll, kqueue: save a pollfd (mem)copy per returned event.
poll, epoll: pollset's pfd is not modified on poll(), mark it const.
====================================================================
At least on Solaris this looks useful. Or do we think that change is to
big to put it into the deps tarball?
And for APR-Util there is r1825312. From CHANGES:
*) apr_dbm_gdbm: Fix handling of error codes. This makes gdbm 1.14 work.
apr_dbm_gdbm will now also return error codes starting with
APR_OS_START_USEERR, as apr_dbm_berkleydb does, instead of always
returning APR_EGENERAL. [Stefan Fritsch]
and from the commit log:
====================================================================
Fix error handling in gdbm
Only check for gdbm_errno if the return value of the called gdbm_*
function says so. This fixes apr-util with gdbm 1.14, which does not
seem to always reset gdbm_errno.
Also make the gdbm driver return error codes starting with
APR_OS_START_USEERR instead of always returning APR_EGENERAL. This is
what the berkleydb driver already does.
Also ensure that dsize is 0 if dptr == NULL.
(backport of r1825311 in apr trunk)
====================================================================
The risk of breaking things is formally smaller, because builders can
always switch back to the old dependency tarball without the need for a
new httpd release, although that situation would produce a bit of confusion.
Regards,
Rainer
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Daniel Ruggeri <dr...@primary.net>.
On 4/19/2018 7:55 AM, Eric Covener wrote:
>> Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
> No offense intended here, but I did not really see as many html /
> script / process updates as I had expected. I was hoping the new eyes
> would get some of this stuff more explicit so it wasn't such a
> mystery.
Totally my fault. I just pushed the last bit of the scripts (I had set a
TODO to do it after we had reviewed in on private@, but failed to
complete the TODO). I still owe doc updates AND the promised docker
image to make the endeavor completely trivial.... but basically, I've
distilled the process down to this set of commands from the tools directory:
unset DISPLAY
TAG="2.4.33"
./tag.sh 2.4.x $TAG /tmp/foo
./release.sh --latestapxxx --tag $TAG '' httpd-2.4 $TAG
'druggeri@primary.net'
./push.sh . $TAG dev
#Wait for vote
./push.sh . $TAG dist
#Wait for mirrors
./announce.sh $TAG 'druggeri@apache.org' 'Daniel Ruggeri'
The only hangup so far is when we merge in security fixes right before
announce - if the patch in the private repo doesn't merge into CHANGES
cleanly, we end up with confusing CHANGES entries. This can be resolved
by a manual check or even an immediate fix after the script is run.
There are also a few XXX and TODO sections that could be addressed with
some more sophisticated automation.
--
Daniel Ruggeri
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Eric Covener <co...@gmail.com>.
> Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
No offense intended here, but I did not really see as many html /
script / process updates as I had expected. I was hoping the new eyes
would get some of this stuff more explicit so it wasn't such a
mystery.
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Stefan Eissing <st...@greenbytes.de>.
Daniel,
would you find it feasible to make a 2.4 release every first Tuesday of the month? Other projects have excellent experiences with such release timings.
I‘d expect this would let us focus on the changes („one more week until release“), take off pressure („we can do it in the next release“), avoid meta discussions („is this a good time?“) and let us streamline the test/release work with changes in process/automation with a higher motivation.
Again, this would be your burden and call until we have so much routine/automation that everyone can do it. So it needs to be your decision.
Cheers, Stefan
> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <dr...@primary.net>:
>
> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
>> Hours, yes, but we've had a willing RM, who has automated even
>> more of this than Jim or I had, and has a very hard time finding
>> any target to point to. E.g. "ok, that looks like the right resolution
>> to the last of the regressions... let's..." ... "...oh there are all these
>> other shiny objects in STATUS... rock-n-roll!!!"
>> ...
>
> What's particularly interesting to me, as I follow the conversation in
> my usual lurker-mode, is that Bill hit the nail on the head with this
> observation. I was waiting for the dust to settle to run through the
> scripts again for another T&R and release vote... but am not totally
> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> the merging discussion so instead started parsing for "Yep. We're good
> now.")
>
> My current read on the conversation is that we're happy (or maybe just
> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
> a fix. Does anyone disagree?
>
> --
> Daniel Ruggeri
>
Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning?
(Was: 2.4.3x regression w/SSL vhost configs)]
Posted by Eric Covener <co...@gmail.com>.
On Wed, Apr 18, 2018 at 6:43 PM, Daniel Ruggeri <dr...@primary.net> wrote:
> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>> The release cycle is hours, to the benefit of all interested. Be it a blocking bug fixed or a nice feature implemented. These are mostly people who do it for fun. Some even run large server clusters, so a „hobbyist“ label does not apply.
>> Hours, yes, but we've had a willing RM, who has automated even
>> more of this than Jim or I had, and has a very hard time finding
>> any target to point to. E.g. "ok, that looks like the right resolution
>> to the last of the regressions... let's..." ... "...oh there are all these
>> other shiny objects in STATUS... rock-n-roll!!!"
>> ...
>
> What's particularly interesting to me, as I follow the conversation in
> my usual lurker-mode, is that Bill hit the nail on the head with this
> observation. I was waiting for the dust to settle to run through the
> scripts again for another T&R and release vote... but am not totally
> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> the merging discussion so instead started parsing for "Yep. We're good
> now.")
>
> My current read on the conversation is that we're happy (or maybe just
> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
> a fix. Does anyone disagree?
I am not sure we have that fix yet in 2.4.x yet.
I think we should call the proxy thing (62308) a showstopper and not
roll a release without it.