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

[Vijay Bellur]

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.

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.

-Vijay