++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 >>> >> >
