[Gluster-Maintainers] glusterfs-3.12.1 released

[Niels de Vos]

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 <srangana at redhat.com> wrote:
> > > 
> > > > On 09/11/2017 11:48 PM, Amye Scavarda wrote:
> > > > > On Mon, Sep 11, 2017 at 8:35 PM, Amar Tumballi <atumball at redhat.com>
> > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > On 12-Sep-2017 6:47 AM, "Atin Mukherjee" <amukherj at redhat.com> 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