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 <srang...@redhat.com> wrote:
On 11/10/2016 11:01 AM, Vijay Bellur wrote:
On Thu, Nov 10, 2016 at 10:49 AM, Shyam <srang...@redhat.com> wrote:
On 11/10/2016 10:21 AM, Vijay Bellur wrote:
On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
<manikandancs...@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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
