On Thu, Nov 10, 2016 at 11:56 AM, Niels de Vos <ndevos@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> > On 11/10/2016 11:01 AM, Vijay Bellur wrote: >> >> >> >> On Thu, Nov 10, 2016 at 10:49 AM, Shyam <srangana@xxxxxxxxxx> wrote: >> >>> >> >>> >> >>> >> >>> On 11/10/2016 10:21 AM, Vijay Bellur wrote: >> >>>> >> >>>> >> >>>> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh >> >>>> <manikandancs333@xxxxxxxxx> 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
