I am laughing at this because one of the reasons why things like gluster and openstack are no longer available in EPEL was because they were moving too fast for users and we were getting complaints about those package changes being broken.--
I don't remember anyone complaining, per se, about this with GlusterFS.
One of the issues I have with EPEL that I think the CentOS SIG's solves is the communication channels for products. If you 'break' someone you get the complaint to you. In EPEL products like openstack, gluster, etc end up pinging someone on the EPEL committee first to fix it for them... so most of the complaints when these things happen don't get to your team. This is one big reason I am not asking/begging etc to have gluster back in EPEL. It is not a good fit. You don't get what you want from us, and people don't communicate their problems to you.
What I do remember is that, independent of any complaints there may or may not have been, I retired GlusterFS in EPEL when Red Hat started shipping GlusterFS as a product, because EPEL policy stipulated that we could not ship packages that are/were in RHEL.
Yes. Parts of gluster got pulled into the channels we said we wouldn't overload.. and that made having it in EPEL not allowed.
One issue we did have in EPEL was the inability to concurrently ship two or more major versions of GlusterFS for each of the actively maintained branches of GlusterFS; something that the CentOS Storage SIG does allow us to do. I.e. some people who were using, e.g., GlusterFS 3.4.x in production on RHEL/CentOS did not want to be forced to update their systems to GlusterFS 3.5.x, and then later on GlusterFS 3.6.x, 3.7.x, 3.8.x, and so on.
Again completely agree with. This is not what EPEL is a good fit for without a lot of work. Supposedly this will all be fixable in our modular future... but that is a 2-3 year long journey fro anyone.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel