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. 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
