Re: AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
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 <ruediger.pluem@xxxxxxxxxxxx>:
> 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"
>> -----Ursprüngliche Nachricht-----
>> Von: Jim Jagielski <jim@xxxxxxxxxxx>
>> Gesendet: Donnerstag, 19. April 2018 15:06
>> An: dev@xxxxxxxxxxxxxxxx
>> 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
>> <stefan.eissing@xxxxxxxxxxxxx> wrote:
>>> 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
>>> 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
>>> Cheers, Stefan
>>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri <druggeri@xxxxxxxxxxx>:
>>>> 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
>>>>> to the last of the regressions... let's..." ... "...oh there are all
>>>>> other shiny objects in STATUS... rock-n-roll!!!"
>>>> What's particularly interesting to me, as I follow the conversation
>>>> 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
>>>> My current read on the conversation is that we're happy (or maybe
>>>> content) with the SSL merging fixes and we should prep to ship 2.4.34
>>>> a fix. Does anyone disagree?
>>>> Daniel Ruggeri