On 02/17/17 09:33, Shyam wrote:
On 02/17/2017 12:01 PM, Niels de Vos wrote:
I've been preparing the GlusterFS 3.10 released for the CentOS Storage
SIG, and that means I need to craete a new centos-release-gluster310
package. This is the package that users install when they want to enable
the YUM repository from the SIG.
Users are recommended to execute the following commands:
# yum install centos-release-gluster
When users *chose* the above, what did they actually choose to do?
Stay at the latest LTM for Gluster?
What I mean is, when a user chooses explicitly to do "yum install
centos-release-gluster38", the choice is clear, they want to be on 3.8
till they choose to add the repo for 3.10 or other.
So, in the former case, when they chose to add centos-release-gluster,
what was the choice made? To stay at the latest LTM, then we should
modify it, else we should not.
centos-release-gluster should be the most long-term stable release
possible. Bugs should be fixed, security issues as well, obviously. No
new features. No API changes, imho.
If a systems engineer wants to test or deploy a specific version, they
should have to take on that responsibility manually.
At a later date when we choose to modify it to say 3.10.x (x>0), what
is the decision based on? How do we communicate that to the users?
# yum install glusterfs-server
Now, the current default for centos-release-gluster is that GlusterFS
3.8.x is made available. Users can install centos-release-gluster39
explicitly, but it is not an update that will replace the 3.8 version.
Should the centos-release-gluster package (well, it is privided by
others) install the 3.8 YUM repository for a while until 3.10.1 is
released (or such)? Or, shall I make 3.10 the new default?
I think I understand your thought process here, which I presume is to
gain a level of stability in 3.10 (if it is not the case out of the
door), before unleashing it on unsuspecting users.
For me it depends on what centos-release-gluster means, and defining
the criteria for updating the same, which then becomes easier to repeat.
I aim to not replace the existing 3.8 deployments, they can stay on 3.8
for an other ~6 months:
https://www.gluster.org/community/release-schedule/
Thanks,
Niels
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
