Howdy,
There are several "release" packages in the Extras repository for SIGs and third party repositories.
centos-release-virt-common centos-release-openstack epel-release
Currently there are no guidelines for other third party repositories to be included, so I wrote this document.
https://wiki.centos.org/CarlGeorge/CATPR
What is this document missing? Are there any additional rules that need to be added for a third party repository to be considered? Also, if these guidelines are accepted, what does the approval process look like? Obviously repositories would be evaluated on a case-by-case basis, but who has the final say on whether a repository is approved or not?
Carl George IUS CoreDev Team
On 09/28/2015 10:58 AM, Carl George wrote:
Howdy,
There are several "release" packages in the Extras repository for SIGs and third party repositories.
centos-release-virt-common centos-release-openstack epel-release
EPEL is a special case .. as voted on by the CentOS Board.
Other ones are SIGs .. which is the way to get a release file into extras.
Currently there are no guidelines for other third party repositories to be included, so I wrote this document.
I am certainly open to discussion .. however, there exists a way to make this happen. We start a Hosting SIG and those RPMs get put in there and built on our CBS.
What is this document missing? Are there any additional rules that need to be added for a third party repository to be considered? Also, if these guidelines are accepted, what does the approval process look like? Obviously repositories would be evaluated on a case-by-case basis, but who has the final say on whether a repository is approved or not?
Carl George IUS CoreDev Team
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
T
On 09/29/2015 01:33 PM, Trevor Hemsley wrote:
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
Well .. RDO, who produces RPMs for RHEL, builds things on CBS.
Packages built on CBS could also work on SL.
I am NOT saying we can never get other repo release files in CentOS-Extras .. I am just saying that there is an easy way to make it happen right now and that is a SIG.
I am only 11% of the CentOS Board .. so I'm sure there is room for movement in many directions on this. But, personally, if we are offering an open program to get things into CentOS, I don't like making exceptions. Everyone thinks THEIR exception is a good one and people want to keep their secret sauce (or build logs, root logs, or build root, etc) private. I would rather everyone work thorough our community setup. I think that is better for CentOS users. They have one place to go to in order to find stuff. If everyone uses it then it is better for everyone in the long run.
We are having ppc64 and ppc64le being redone on our hardware and in a way that it can be integrated into CBS and this infrastructure. The people doing that did not necessarily think that was a great idea either .. but I also think that will be better in the long run too.
However, by all means, if users and the board want to create this mechanism, this is the place to hash it out.
On 09/30/2015 11:50 AM, Johnny Hughes wrote:
On 09/29/2015 01:33 PM, Trevor Hemsley wrote:
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
Well .. RDO, who produces RPMs for RHEL, builds things on CBS.
Packages built on CBS could also work on SL.
I am NOT saying we can never get other repo release files in CentOS-Extras .. I am just saying that there is an easy way to make it happen right now and that is a SIG.
I am only 11% of the CentOS Board .. so I'm sure there is room for movement in many directions on this. But, personally, if we are offering an open program to get things into CentOS, I don't like making exceptions. Everyone thinks THEIR exception is a good one and people want to keep their secret sauce (or build logs, root logs, or build root, etc) private. I would rather everyone work thorough our community setup. I think that is better for CentOS users. They have one place to go to in order to find stuff. If everyone uses it then it is better for everyone in the long run.
We are having ppc64 and ppc64le being redone on our hardware and in a way that it can be integrated into CBS and this infrastructure. The people doing that did not necessarily think that was a great idea either .. but I also think that will be better in the long run too.
However, by all means, if users and the board want to create this mechanism, this is the place to hash it out.
And before this starts getting crazy .. I know and trust ultimately the elrepo people .. and also Carl from rackspace. I know we can trust their work in this regard with no issues. But eventually, people we don't know and trust implicitly will ask join the program as well .. and the rules need to work for them also.
On 30/09/15 17:50, Johnny Hughes wrote:
On 09/29/2015 01:33 PM, Trevor Hemsley wrote:
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
Well .. RDO, who produces RPMs for RHEL, builds things on CBS.
Packages built on CBS could also work on SL.
I am NOT saying we can never get other repo release files in CentOS-Extras .. I am just saying that there is an easy way to make it happen right now and that is a SIG.
I am only 11% of the CentOS Board .. so I'm sure there is room for movement in many directions on this. But, personally, if we are offering an open program to get things into CentOS, I don't like making exceptions. Everyone thinks THEIR exception is a good one and people want to keep their secret sauce (or build logs, root logs, or build root, etc) private. I would rather everyone work thorough our community setup. I think that is better for CentOS users. They have one place to go to in order to find stuff. If everyone uses it then it is better for everyone in the long run.
We are having ppc64 and ppc64le being redone on our hardware and in a way that it can be integrated into CBS and this infrastructure. The people doing that did not necessarily think that was a great idea either .. but I also think that will be better in the long run too.
However, by all means, if users and the board want to create this mechanism, this is the place to hash it out.
Johnny, I'm a little confused so could you please just clarify? Are you proposing the 3rd party repo release file would be (re)built on the CentOS CBS and be included, or are you saying that the complete 3rd party repo (all packages) would be rebuilt on CBS?
Because if it's the former, then I doubt there's any secret sauce involved, and if it's the latter then it's no longer 3rd party "elrepo", or otherwise <insert other 3rd party repo here>.
Just seeking clarification as the thread reads a little ambiguous to me :-)
Thanks!
On 09/30/2015 12:17 PM, Ned Slider wrote:
On 30/09/15 17:50, Johnny Hughes wrote:
On 09/29/2015 01:33 PM, Trevor Hemsley wrote:
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
> EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
Well .. RDO, who produces RPMs for RHEL, builds things on CBS.
Packages built on CBS could also work on SL.
I am NOT saying we can never get other repo release files in CentOS-Extras .. I am just saying that there is an easy way to make it happen right now and that is a SIG.
I am only 11% of the CentOS Board .. so I'm sure there is room for movement in many directions on this. But, personally, if we are offering an open program to get things into CentOS, I don't like making exceptions. Everyone thinks THEIR exception is a good one and people want to keep their secret sauce (or build logs, root logs, or build root, etc) private. I would rather everyone work thorough our community setup. I think that is better for CentOS users. They have one place to go to in order to find stuff. If everyone uses it then it is better for everyone in the long run.
We are having ppc64 and ppc64le being redone on our hardware and in a way that it can be integrated into CBS and this infrastructure. The people doing that did not necessarily think that was a great idea either .. but I also think that will be better in the long run too.
However, by all means, if users and the board want to create this mechanism, this is the place to hash it out.
Johnny, I'm a little confused so could you please just clarify? Are you proposing the 3rd party repo release file would be (re)built on the CentOS CBS and be included, or are you saying that the complete 3rd party repo (all packages) would be rebuilt on CBS?
I am talking about all the packages. And what I mean by secret sauce is .. if someone created a different version of a package (for example, maybe a different samba or firefox with different compile options .. and the same name), then we would not necessarily know that by even looking at the build logs. We would KNOW everything if it is built on CBS. Not only do we all know everything, it can be reproduced completely.
Because if it's the former, then I doubt there's any secret sauce involved, and if it's the latter then it's no longer 3rd party "elrepo", or otherwise <insert other 3rd party repo here>.
Right, it would be a SIG's release file.
Just seeking clarification as the thread reads a little ambiguous to me :-)
I am saynig that 3rd Party repos which are SIGs are no longer really 3rd party .. and they get in automatically. And we have a process for that already. And that users win and the community wins when we all work together.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2015 12:25 PM, Johnny Hughes wrote:
I am talking about all the packages. And what I mean by secret sauce is .. if someone created a different version of a package (for example, maybe a different samba or firefox with different compile options .. and the same name), then we would not necessarily know that by even looking at the build logs. We would KNOW everything if it is built on CBS. Not only do we all know everything, it can be reproduced completely.
Adding some additional thoughts to consider, depending on what is in the third-party repo ...
We have the same restriction the CentOS Project always had around software needing to be redistributable including in the US. Meaning not only an appropriate distribution license (FLOSS being the best), but also considering the DMCA and software patents and so forth.
So if a repo that is currently third-party has that sort of material, it cannot be brought in to the CBS with those materials in it.
It also means we likely cannot distribute the package repo RPM file with CentOS Linux, as that would be pointing directly to infringing software.
Of course, it's worth mentioning IANAL, I'm just speaking from experience here.
Kind regards,
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On 30/09/15 20:25, Johnny Hughes wrote:
On 09/30/2015 12:17 PM, Ned Slider wrote:
On 30/09/15 17:50, Johnny Hughes wrote:
On 09/29/2015 01:33 PM, Trevor Hemsley wrote:
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
>> EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
Well .. RDO, who produces RPMs for RHEL, builds things on CBS.
Packages built on CBS could also work on SL.
I am NOT saying we can never get other repo release files in CentOS-Extras .. I am just saying that there is an easy way to make it happen right now and that is a SIG.
I am only 11% of the CentOS Board .. so I'm sure there is room for movement in many directions on this. But, personally, if we are offering an open program to get things into CentOS, I don't like making exceptions. Everyone thinks THEIR exception is a good one and people want to keep their secret sauce (or build logs, root logs, or build root, etc) private. I would rather everyone work thorough our community setup. I think that is better for CentOS users. They have one place to go to in order to find stuff. If everyone uses it then it is better for everyone in the long run.
We are having ppc64 and ppc64le being redone on our hardware and in a way that it can be integrated into CBS and this infrastructure. The people doing that did not necessarily think that was a great idea either .. but I also think that will be better in the long run too.
However, by all means, if users and the board want to create this mechanism, this is the place to hash it out.
Johnny, I'm a little confused so could you please just clarify? Are you proposing the 3rd party repo release file would be (re)built on the CentOS CBS and be included, or are you saying that the complete 3rd party repo (all packages) would be rebuilt on CBS?
I am talking about all the packages. <snip rest of answer>
Thanks for the clarification.
Regarding the point about "secret sauce", I can clarify the differences between public IUS and what Rackspace offers our customers. It's not so much "secret" as it is just poorly documented.
* Public IUS offers packages built against the latest base releases of RHEL and CentOS. * Internally at Rackspace, business needs dictate that we also build IUS packages against supported RHEL EUS point releases (in addition to the latest base releases).
Our build farm is currently private and is configured to build for both public and internal needs in the same build. Here is an overview of the steps that are taken.
1. build requested 2. build farm builds packages for RHEL {6, 6.5, 6.6, 6.7, 7, 7.1} and CentOS {6, 7} 3. automation copies base and EUS packages to an internal server and signs with our internal key 4. automation copies just base packages to a public server and signs with our public key
Eventually converting IUS into a CentOS SIG is an intriguing idea, but may be limited in our use case since I don't believe CBS can build for RHEL EUS releases (please correct me if I am wrong). Maybe that just means that we have to double our work and run duplicate builds in the CBS infrastructure and internally.
Just to clarify, I don't necessarily want to keep our EUS rebuilds private, that is just how the project was set up initially.
Carl George IUS CoreDev Team
2015-09-30 18:50 GMT+02:00 Johnny Hughes johnny@centos.org:
On 09/29/2015 01:33 PM, Trevor Hemsley wrote:
On 29/09/15 17:35, Johnny Hughes wrote:
On 09/28/2015 10:58 AM, Carl George wrote: >> Howdy, >> >> There are several "release" packages in the Extras
repository for SIGs and >> third party repositories. >> >> centos-release-virt-common >> centos-release-openstack >> epel-release
EPEL is a special case .. as voted on by the CentOS Board. > >
Other ones are SIGs .. which is the way to get a release file into extras. > > >> Currently there are no guidelines for other third party repositories to be >> included, so I wrote this document. >> >> https://wiki.centos.org/CarlGeorge/CATPR >> > > I am certainly open to discussion .. however, there exists a way to make > this happen. We start a Hosting SIG and those RPMs get put in there and > built on our CBS.
That appears to rule out elrepo and IUS ever being allowed to get into extras which seems like a change of policy from before when it was: "come up with some criteria by which we can make impartial decisions". In both cases, they do not target CentOS alone, they exist to serve the entire EL community. Making them build in CBS would then rule out their repos being used on RHEL and/or SL. I don't think this is a good idea either.
Well .. RDO, who produces RPMs for RHEL, builds things on CBS.
Packages built on CBS could also work on SL.
I am NOT saying we can never get other repo release files in CentOS-Extras .. I am just saying that there is an easy way to make it happen right now and that is a SIG.
I am only 11% of the CentOS Board .. so I'm sure there is room for movement in many directions on this. But, personally, if we are offering an open program to get things into CentOS, I don't like making exceptions. Everyone thinks THEIR exception is a good one and people want to keep their secret sauce (or build logs, root logs, or build root, etc) private. I would rather everyone work thorough our community setup. I think that is better for CentOS users. They have one place to go to in order to find stuff. If everyone uses it then it is better for everyone in the long run.
We are having ppc64 and ppc64le being redone on our hardware and in a way that it can be integrated into CBS and this infrastructure. The people doing that did not necessarily think that was a great idea either .. but I also think that will be better in the long run too.
However, by all means, if users and the board want to create this mechanism, this is the place to hash it out.
Excellent answer.
My PoV as a SIG member: Until then, EL community has been scattered, and now we have a common place for people wanting to build features/products on top of EL while *respecting* that diversity. (CBS is *Community* Build System not CentOS) If you care about compatibility against RHEL/SL/whatever => contribute more CI against packages to detect incompatibilities.
In one year, for RDO packages, we found a *single* compatibility issue with RHEL 7.1 was released, and it was solved rather quickly. For the record, we had the very same issue internally with RHEL 7.0. That's quite minor, and I prefer improving SIG infrastructure rather wasting efforts on creating a new one from scratch.
CentOS is saving us a lot of efforts and time by providing that infrastructure, so that such issues are not relevant to consider doing otherwise. Kudos to the Core SIG for their efforts.
H.
-
Carl George -
Haïkel -
Johnny Hughes -
Karsten Wade -
Ned Slider -
Trevor Hemsley