[Gluster-Maintainers] glusterfs-3.12.1 released

[Shyam Ranganathan]

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)

> 
> I am of the opinion that even if there is a single bugfix that would
> help some users, we should do the release.

+1

> 
> I think it is important for users to have the regular releases, and on
> time. Every time a release gets delayed, packagers will need to adjust
> their planning too.

+1

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

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.

> 
> Niels
> 
> 
>>
>>
>>>
>>>>>
>>>>>
>>>>> As per the schedule? It's 10days since release.
>>>>>
>>>>> -Amar
>>>>
>>>> Said another way, we have a scheduled maintenance day of the 10th for
>>>> this particular release:
>>>> https://www.gluster.org/release-schedule/
>>>>
>>>> Happy to welcome changes to this that make sense, because yes, it
>>>> periodically collides like this!
>>>
>>> Minor releases are bug fix releases, so things available as bug fixes
>>> will be pushed out. So if we want this changed, there needs to be
>>> reasoning around it as well (just saying).
>>>
>>>> -- amye
>>>>
>>>>>
>>>>> On Mon, 11 Sep 2017 at 22:58, Gluster Build System
>>>>> <jenkins at build.gluster.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> SRC:
>>>>>>
>>> http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.12.1.tar.gz
>>>>>>
>>>>>> This release is made off v3.12.1
>>>>>>
>>>>>> -- Gluster Build System
>>>>>> _______________________________________________
>>>>>> maintainers mailing list
>>>>>> maintainers at gluster.org
>>>>>> http://lists.gluster.org/mailman/listinfo/maintainers
>>>>>
>>>>> --
>>>>> - Atin (atinm)
>>>>>
>>>>> _______________________________________________
>>>>> maintainers mailing list
>>>>> maintainers at gluster.org
>>>>> http://lists.gluster.org/mailman/listinfo/maintainers
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> maintainers mailing list
>>>>> maintainers at gluster.org
>>>>> http://lists.gluster.org/mailman/listinfo/maintainers
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> maintainers mailing list
>>> maintainers at gluster.org
>>> http://lists.gluster.org/mailman/listinfo/maintainers
>>>
>> -- 
>> - Atin (atinm)
> 
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org
>> http://lists.gluster.org/mailman/listinfo/maintainers
>