On Thu, Jul 19, 2018 at 8:50 AM Jeroen Demeyer <[email protected]> wrote: > > On 2018-07-19 00:24, Volker Braun wrote: > > Since Erik is clamoring for a more calendar-driven release schedule, > > here is a quick A/B test: > > > > A) Keep the current process of releasing approximately every 3 months, > > longer if people insist on having their own pet tickets merged at the > > last minute. > > > > B) Keep a strict time table: Merge window is open for 2 months, after > > that only fixes for new regressions, release on 1/1, 3/1, 6/1, and 9/1. > > From my personal experience as release manager, I would have hated B. > > However, I think Erik was asking more for something like > > C) Don't keep a strict time table, but announce at some point during the > beta releases when you plan to cut off the merge window.
I prefer something like B, but as I also wrote it can certainly have flexibility: E.g. if the release manager is going to be on vacation on 3/1 then the release can be delayed until 3/7 or whatever. Or if there are other delays (such as a critical bug found in pre-release window that absolutely must be fixed before a release can be made; a not usual but not unheard of event) that's certainly acceptable too. No one is forcing us to release on that exact schedule. What I meant for "B" is less a "strict time table" and more of an idealized plan that is subject to change. In the commercial world we do this all the time. You make a plan ahead of time so you can reason about it. The plan is allowed to--and is almost inevitably going to change. But having a plan gives you something to aspire to and, by definition, reason about. There's more to planning that that, but that's the bare minimum. It doesn't have to be anything so formal. The Trac "Roadmap" page allows you to set dates for milestones. We can put it there, using a 3 or 4 month interval as a rough estimate, and then adjust as needed (with discussion; communication, of course, not just one person changing the date and not mentioning anything). However, if even that is too annoying you're correct that I offered such a "C", and I think you characterized it more-or-less accurately. The community deserves to know how much time they have before the next cut-off for making a release, and the opportunity to express what their priorities are determine whether or not they are reasonable within the remaining window (with some flexibility for lengthening the window if we can agree that some change is critical enough for the next release). This communication of priorities can be done both directly through discussion, as well as--what I would ask people to do if I were release manager--triaging your own tickets to give a better estimate of what you expect to do for the upcoming release milestone, and how you prioritize those issues. This usually should only take a few minutes and is not absolutely necessary, but it does help. One needs a chance to do that though; once you start making "release candidates" such triaging is not as immediately useful. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
