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

[Niels de Vos]

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

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20161110/e6657932/attachment.sig>