I don't think Stefan is proposing that we mindlessly ship based on an arbitrary set of dates. That'd be too.... corporate :-)
I think in the past you mentioned that we have had features/fixes/Good Stuff(tm) that was probably *ready*... just not yet released. I do recall a few times where there have been fixes in 2.4.x branch that I was frustrated as a user (burdened with the knowledge of a developer) for having to wait to hit a release... so my main objective with the automation is to simply make it simple to do a release so we aren't entirely dependent on you and Bill to get those fixes/features/whatever it may be into our users' hands. Referring to the other message I just sent. I want to stress the fact that now, with a few commands and *some* manual work (mostly when there are CVEs to address), anyone can do a release. There's value in this - especially given the fact that I truly did pore through and intensively examine/internalize the documentation yet STILL managed to burn a version number due to rookie mistakes. The third option along with status quo or automation would be for the next unfortunate committer to stumble through the process themselves and, possibly, make the same mistakes I did. Besides, heck... as you say, this is Open Source. We're volunteers and this is the kind of stuff I actually do like to work on. CI/CD and the like are a Good Thing :thumbsup: Specifically to your question, Stefan... you beat me to it. Since the last time I executed the release, I put in a quarterly reminder on my calendar to check STATUS and help shuffle a release out the door if there are no showstoppers and if we had added anything that looked cool. I plan to stick by that schedule and also try to keep a pulse on the project for times where we should ship a release sooner. -- Daniel Ruggeri On 4/19/2018 8:06 AM, Jim Jagielski wrote: > 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 >>>
