I can agree with the logic. Me and Andrew Cutler had actually originally established the Ascendos project during that awkward period when CentOS was actually having issues maintaining transparency (along with the resulting development hell of CentOS 6); as such, transparency and keeping an open development process was our main goal. But our other major goal for it was to try and get all the other "minor" EL rebuilders (i.e. PUIAS, Scientific, but more successfully GoOSe, as you may have noticed) to unite under our platform to reduce duplicated effort (ironically, this appears to what you're trying to push with the "new" CentOS). We ended up hitting a roadblock from some internal drama, though we did get /one/ build out.
Me and some others also had concerns about the implications of certain statements within the FAQ, which seemed to either suggest that CentOS was no longer aiming to be 100% binary compatible (and is being meddled with by RH), or that RH was just trying to use FUD to still push RHEL sales (i.e. "While CentOS delivers a distribution with strong community support, Red Hat Enterprise Linux provides a stable enterprise platform with a focus on security, reliability, and performance", and the claim that "While CentOS is derived from the Red Hat Enterprise Linux codebase, CentOS and Red Hat Enterprise Linux are distinguished by divergent build environments, QA processes, and, in some editions, different kernels and other open source components. For this reason, the CentOS binaries are not the same as the Red Hat Enterprise Linux binaries", despite binary compatibility remaining one of the things that the CentOS team were really focused on.)
But yes, I agree with the notion that CentOS should not be treated as the cathedral of EL; we should still be able to do things in the ways we want, while having a community group within help ensure that they remain a bazaar. Let's go with a tasty, sugar-filled analogy: CentOS/RHEL is not Pepsi/Coke, it's more like President's Choice and Coke. EL re-spins are like store-brand cola; most store-brand colas are just re-branded, white label product from another major company. But through marketing and, perhaps, other minor differences (i.e. taste, store loyalty), they still compete. This case sorta applies here too; they all have their own special communities (Scientific focuses on academic/scientific use, and CentOS on just trying to be a simple store brand) and special needs. And I also agree with the idea about the build chain; the success of an open source project is fueled more by the userbase than anything else.
You've hit the nail on the head quite well there, Wade.
-- Shawn
On Wed, Jan 29, 2014 at 12:33 PM, Karsten Wade kwade@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/29/2014 07:39 AM, Clint Savage wrote:
The value of a separate rebuild is not about duplicating effort. It's more about using and improving the tools in a separate environment. I have found that as a tool grows, it needs multiple contributors from different environments to become full featured, more secure, etc. Having separate communities contributing to CentOS in the form of a SIG seems like one way to homogenize the effort, removing some of these opportunities for improving tooling and the distribution itself.
While I definitely see the value of doing all the things in one place within CentOS -- or I wouldn't have worked on the project to get us here -- I'm also realistic that not everyone will want or be able to come to the one place to do all the things. At the minimum, it's a good thing to have an open communication channel with rebuilders who want to do their work outside of the CentOS environment; it might make sense to have that channel more formalized as a group.
There is another lesson I'm trying to learn from, an example of which is the Fedora build toolchain (Koji, Bodhi, etc.) I've talked with people who share a concern that the build tools are missing the chance to be better because they are not massively adopted. There are people using Koji, for example, but AIUI it's not a huge contributor base. Simply having more people using Koji is good for all the users of Koji
- it will help it be more robust and useful through the usual process
of open source development benefiting from a sizeable userbase.
Thus my thinking that an interoperability SIG would fulfill the communication channel to the inevitably going-their-own-way rebuilders, would provide a way for groups to choose in the future to join the overall CentOS effort in some way, and be a group within CentOS that cares about the tools being useful and used somewhere they weren't invented.
- Karsten
Karsten 'quaid' Wade .^\ CentOS Engineering Manager http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLpSY0ACgkQ2ZIOBq0ODEExvwCgmjwE/wKtSbRLnFe2vJ+fSpEc zawAoM6R10DLKnUB6Mya8zA6B7gvbTnk =YPFg -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel