Hi folks, Our set of packages that we support as "Nautilus on CentOS" is growing, and I expect it to grow even more. In the past, we've been handling each new package as a one-off thing within Jenkins Job Builder, and this is hard to understand and scale. I'd like to take a new look at how we do this. The CentOS project provides some infrastructure for us to build and maintain a set of packages on top of the base OS (CentOS 7 at the moment). CentOS has "SIGs", which are groups of users interested in packaging things on top of CentOS, and Ceph is in the "Storage SIG" along with Gluster (and potentially other storage technologies). My high-level vision here: Using CentOS's build and release infrastructure would allow us to come up with a "known good" set of packages that make up "Nautilus the distribution", which we can QE, containerize, and distribute in a straightforward way. There are some other advantages. CentOS has an incredible mirror network which would save us the trouble of mirroring CentOS RPMs like we do with the chacra VMs and download.ceph.com. They have a standard way to sign RPM content, and that's often been a troublesome part of our release process at download.ceph.com. The user experience is simplified for our CentOS users, because the "nautilus-release" package will already be available in CentOS Extras, so there's no .repo file that users have to configure, or GPG key to trust manually. Niels de Vos works on Gluster and he is the Storage SIG chair, and he's really responsive to our needs so far. The CentOS administrators also meet every week to discuss the buildsystem in #centos-devel. This email is light on the technical details, but I wanted to get the thoughts out here. - Ken
