Re: AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

2018-04-19 Thread Stefan Eissing 
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 
> :
> 
> 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 
>> 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
>>  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 :
 
 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 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)]

2018-04-19 Thread Plüm , Rüdiger , Vodafone Group 
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 
> 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
>  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 :
> >>
> >> 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 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
> >>
> >