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 <i...@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 <j...@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 <stefan.eiss...@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 <drugg...@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 >>>> >>> >> >
