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 > <[email protected]>: > > 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 <[email protected]> >> Gesendet: Donnerstag, 19. April 2018 15:06 >> An: [email protected] >> 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 >> <[email protected]> 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 <[email protected]>: >>>> >>>> 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 >>>> >>> >
