[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:56 AM, Niels de Vos <ndevos at redhat.com> 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.
>
>> 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.
>
> I am not sure how we can handle this in other distributions (or also
> with the packages on d.g.o.).

Maybe we should not flip the LATEST for non-RPM distributions in
d.g.o? or should we introduce LTM/LATEST and encourage users to change
their repository files to point to this?

Packaging in distributions would be handled by package maintainers and
I presume they can decide the appropriateness of a release for
packaging?

Thanks,
Vijay