On Tue, Sep 12, 2017 at 10:19:20AM -0400, Shyam Ranganathan wrote: > On 09/12/2017 08:27 AM, Niels de Vos wrote: > > On Tue, Sep 12, 2017 at 12:19:17PM +0000, Atin Mukherjee wrote: > > > On Tue, 12 Sep 2017 at 16:20, Shyam Ranganathan <[email protected]> > > > wrote: > > > > > > > On 09/11/2017 11:48 PM, Amye Scavarda wrote: > > > > > On Mon, Sep 11, 2017 at 8:35 PM, Amar Tumballi <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > > > > On 12-Sep-2017 6:47 AM, "Atin Mukherjee" <[email protected]> > > > > > > wrote: > > > > > > > > > > > > Can someone please explain what's the reason of doing 3.12.1 so > > > > > > early, > > > > just > > > > > > after 5 days of 3.12? > > > > > > > > May I understand, why the concern? > > > > > > > > > Honestly, I missed the fact that as per our release schedule 3.12.z is > > > scheduled for 10th of every months, so no real objection here, what has > > > been done here is as per the process. > > > > > > On the other side of it, after relooking at .z updates schedule I was just > > > debating with myself do we have to absolutely be strict on the dates > > > especially when a new LTS release is pushed out to the users just few days > > > back and we come out with .1 updates with very limited number of bug > > > fixes? > > > Probably a balance of the timeline and the volume of bug fixes is > > > something > > > to be relooked at? > > It seems like looking at schedule with scope in mind for a minor release, > and in the past that has not worked, there is always something extra in the > scope to be added (hence wait!) or nothing. The current scheme works, with > the understanding around cut off dates and what constitutes backports etc. > (IMO)
Yes, I don't think it is a very important requirement to keep in mind when picking a release date. The initial dates always seem to slip at least a little bit, so the schedule for major releases is more of a rough guideline in any case. ...snip... > > It is unfortunate that the 3.12.0 release did not happen on the 10th of > > August, that would have been ideal. This is probably something that can > > be tried to schedule better for 3.13.0. > > That would be 20 days less than the 3 months, adjusting the major release to > the minor release schedule does not make sense to me. Instead, the first > minor release, is either 10/20/30 days from the major release, works fine > for most purposes IMO. Indeed, it may not really work out well. I don't think anyone cares strongly about it though. > Further, there could be out of band minor release to address a > blocker/security issue, which is the really unplanned one and could cause > confusion, but it would be unavoidable in such cases. Sure, and as long as we explain the intend behind doing releases when they happen, I don't expect anyone to have a problem with it. Thanks, Niels _______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
