[Gluster-Maintainers] [Gluster-devel] Please pause merging patches to 3.9 waiting for just one patch

[Shyam]

On 11/10/2016 11:56 AM, Niels de Vos wrote:
> On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
>> On Thu, Nov 10, 2016 at 11:14 AM, Shyam <srangana at redhat.com> wrote:
>>> On 11/10/2016 11:01 AM, Vijay Bellur wrote:
>>>>
>>>> On Thu, Nov 10, 2016 at 10:49 AM, Shyam <srangana at redhat.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>>>>>> <manikandancs333 at gmail.com> wrote:
>>>>>> Given that we are done with the last release in 3.6.x, I think there
>>>>>> would be users looking to upgrade.  My vote is to include the
>>>>>> necessary patches in 3.9 and not let users go through unnatural
>>>>>> workflows to get quota working again in 3.9.0.
>>>>>
>>>>>
>>>>>
>>>>> <Comment is without knowing if the necessary patches are good to go>
>>>>>
>>>>> Consider this a curiosity question ATM,
>>>>>
>>>>> 3.9 is an LTM, right? So we are not stating workflows here are set in
>>>>> stone?
>>>>> Can this not be an projected workflow?
>>>>>
>>>>
>>>>
>>>> 3.9 is a STM release as per [1].
>>>
>>>
>>> Sorry, I meant STM.
>>>
>>>>
>>>> Irrespective of a release being LTM or not, being able to upgrade to a
>>>> release without operational disruptions is a requirement.
>>>
>>>
>>> I would say upgrade to an STM *maybe* painful, as it is an STM and hence may
>>> contain changes that are yet to be announced stable or changed workflows
>>> that are not easy to upgrade to. We do need to document them though, even
>>> for the STM.
>>>
>>> Along these lines, the next LTM should be as stated, i.e "without
>>> operational disruptions". The STM is for adventurous folks, no?
>>>
>>
>> In my view STM releases for getting new features out early. This would
>> enable early adopters to try and provide feedback about new features.
>> Existing features and upgrades should work smoothly. IOW, we do not
>> want to have known regressions for existing features in STM releases.
>> New features might have rough edges and this should be amply
>> advertised.
>
> I do not think users on 3.6 are the right consumers for a STM release.
> These users are conservative and did not ugrade earlier. I doubt they
> are interested in new features *now*. Users that did not upgrade before,
> are unlikely the users that will upgrade in three months when 3.9 is
> EOL.

Valid and useful point.

But, just to be clear, if we introduce a non-backward compatible upgrade 
process (say) for a feature in an STM, we need to smoothen this out by 
the LTM, and not use the STM as the gate that let the upgrade process 
through and accept it as final.

>
>> In this specific case, quota has not undergone any significant changes
>> in 3.9 and letting such a relatively unchanged feature affect users
>> upgrading from 3.6 does not seem right to me. Also note that since
>> LATEST in d.g.o would point to 3.9.0 after the release, users
>> performing package upgrades on their systems could end up with 3.9.0
>> inadvertently.
>
> The packages from the CentOS Storage SIG will by default provide the
> latest LTM release. The STM release is provided in addition, and needs
> an extra step to enable.

Perfect! This is along the lines of what I had in mind as well. I.e, the 
LTM is provided as the default, and STM is used *by choice*.

>
> I am not sure how we can handle this in other distributions (or also
> with the packages on d.g.o.).
>
> Niels
>