One of the major values of the EL rebuild ecosystem is the ability to interoperate, or the ability to fork from the upstream. This provides purpose in many ways, choice being the most heralded. Since the CentOS community has teamed up with Red Hat to allow for Special Interest Groups to join them, it seems that there might be a bit less of an ecosystem available. The goal of the Interoperability SIG is to ensure that the ability to fork and rebuild still exist.
Our communities already exist outside of the CentOS community purview. They are currently the GoOSe Project[1] and the Ascendos Project[2]. This shared community will serve as a "reference implementation", yet will still be operated and marketed as a product and community separate from CentOS. Consider it something of CentOS "embassy" of sorts.
It would seem that this SIG could be construed as contrary to the goals of the CentOS project. However, we believe there is value added to the CentOS project. We are interested in improving the CentOS community in at least a few ways.
* Providing feedback and collaboration on common issues. Including, but not limited to, reporting bugs, providing patches, discussing packaging techniques, rebuilding variants, QA, ISO building, etc.
* Collaboration on documentation of the rebuild process, rebranding of documentation, providing new documentation, etc.
* Build or maintain tools to ease rebranding of upstream packages as to ease adoption by companies who build upon and release software based on CentOS.
* Providing tools to help monitor statuses of builds, repositories, releases, etc. Whether they be part of the CentOS community or otherwise.
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
Cheers,
Clint Savage
Lead Developer, GoOSe project
1 - http://gooseproject.org (#gooseproject on irc.freenode.net)
2 - http://ascendos.org (#ascendos on irc.freenode.net)
On 01/28/2014 03:46 PM, Clint Savage wrote:
One of the major values of the EL rebuild ecosystem is the ability to interoperate, or the ability to fork from the upstream. This provides purpose in many ways, choice being the most heralded. Since the CentOS community has teamed up with Red Hat to allow for Special Interest Groups to join them, it seems that there might be a bit less of an ecosystem available. The goal of the Interoperability SIG is to ensure that the ability to fork and rebuild still exist.
I consider one of the goals of the new arrangement to be creating more community, or ecosystem. However the way we've structured things so far will (hopefully) homogenize things a bit. I personally consider it a bit of a systemic failure that users have to hunt through any number of 3rd party repos to accomplish what they're after, often getting themselves into trouble in the process.
Our communities already exist outside of the CentOS community purview. They are currently the GoOSe Project[1] and the Ascendos Project[2]. This shared community will serve as a "reference implementation", yet will still be operated and marketed as a product and community separate from CentOS. Consider it something of CentOS "embassy" of sorts.
It's been a stated goal from the beginning of the discussion (on both sides) that we have no 'collateral damage' to other groups who don't want to participate. For other builders, the only thing that should really change would be the location of the source they get.
It would seem that this SIG could be construed as contrary to the goals of the CentOS project. However, we believe there is value added to the CentOS project. We are interested in improving the CentOS community in at least a few ways.
I don't see this as contrary, I see it as independent verification that we're living up to our stated objectives. It does however bring up a minor point of concern. For GoOSe, I only see a release for 6.0 on the download page, and no download option for Ascendos. I'd like some assurance that if your project steps up as a 'validation entity' that it won't falter. If we do this and it lags or dies off, that may reflect poorly on us (the project). It might be construed as either failing to live up to our goals, or intentionally killing it.
- Providing feedback and collaboration on common issues. Including, but not
limited to, reporting bugs, providing patches, discussing packaging techniques, rebuilding variants, QA, ISO building, etc.
Within the CentOS context or GoOSe? How are you proposing that we orchestrate the collaboration between the two?
- Collaboration on documentation of the rebuild process, rebranding of
documentation, providing new documentation, etc.
Same two questions.
- Build or maintain tools to ease rebranding of upstream packages as to
ease adoption by companies who build upon and release software based on CentOS.
This would be useful, but could prove to be a Sisyphean task, given that new packages get added, packages get updated, etc.
- Providing tools to help monitor statuses of builds, repositories,
releases, etc. Whether they be part of the CentOS community or otherwise.
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
I like the idea, and the fact that it provides independent validation, but I'm not sure this fits with the idea of a SIG. The reason I say this is because for code in the sig/variant model, it needs to live on git.centos.org so that it could be built/signed by the project, which seems counter to the whole 3rd party validation this would provide.
Because what you're proposing would live outside the structure and exist as an outside entity, does it make sense to be a SIG, or simply to have an understanding between groups?
Cheers,
Clint Savage
Lead Developer, GoOSe project
1 - http://gooseproject.org (#gooseproject on irc.freenode.net)
2 - http://ascendos.org (#ascendos on irc.freenode.net)
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/28/2014 05:44 PM, Jim Perrin wrote:
On 01/28/2014 03:46 PM, Clint Savage wrote:
- Build or maintain tools to ease rebranding of upstream packages as to
ease adoption by companies who build upon and release software based on CentOS.
This would be useful, but could prove to be a Sisyphean task, given that new packages get added, packages get updated, etc.
To help others not do the legwork I did (from en.wiktionary.org://sisyphean)
"Sisyphus was a Greek mythological figure who was doomed to endlessly roll a boulder up a hill in Hades."
lol :)
Note, while I worked as Ascendos lead developer for some time, I'm speaking now just as a random individual with a past, and possibly future interest in rebuilding EL from source on a standalone system. Ideally a single outtermost wrapper script command. And ideally with a pair of arguments- a new distro name, and a new distro logo. And then, the right Sisyphean task completed by the tireless computer system with sufficient automating instructions.
To that end, I'd like to say that I think the 'sisyphean' comment doesn't fit my picture of where things are. My perception is that historically redhat has had a choice. A choice of making the task of rebranding drastically more or less sisyphean. While I haven't been paying that close attention the last couple years, the general feeling I get, is that they want to have a good reputation, and take the non-sisyphean track. Note, there are 2 different levels of rebranding here. One level, which I've been talking about, is complying with redhat on trademarks. The next level is complying with every last trademark holder in the distro. Dealing with this latter is/was perhaps my sisyphean task. Because ultimately what I wish to empower, is any and every single 10 year old computer wiz, being able to trivially have in front of them- every line of source of a massive distro like EL, and be able to modify any line of that source in any way they want, and with a totally tractable trivial minimal effort (15 minutes of active participation tops) be able to kick off a rebuild of their own forked distro, that they have full rights to redistribute as freely as they please. Getting there may be sisyphean, but I really think it is doable and worth doing.
But just dealing with the redhat/centos marks should be IMO a totally non-sisyphean a task. Given my estimation of redhat's intent and past actions on this are accurate. I.e, there is not so much effort with new and churning packages as I think you suggest. I posit that most of the trouble was with historical packages before people had really spent much time thinking about it. Am I wrong on that? Has the amount of Redhat->CentOS mark scrubbing not gone down dramatically v4->5->6->7 ?? Is it really a 'sisyphean task' to finally get it down to 0 with all marks-in-need-of-scrubbing only in a couple packages (redhat-logos, etc)?
- Providing tools to help monitor statuses of builds, repositories,
releases, etc. Whether they be part of the CentOS community or otherwise.
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
I like the idea, and the fact that it provides independent validation, but I'm not sure this fits with the idea of a SIG. The reason I say this is because for code in the sig/variant model, it needs to live on git.centos.org so that it could be built/signed by the project, which seems counter to the whole 3rd party validation this would provide.
I think there is a large area for build tools that are the 'blessed way' to build the source from scratch. 'blessed' by centos/redhat (are we allowed to utter that name more freely on the list these days?). But validated by others easily able to fetch them, audit the code and configuration to their hearts desire, and rebuild with or without enhancements of their own. Probably much of this already exists, I think the spirit of this topic is just committing to the whole of the picture. Commitment could come in the form of an ongoing SIG, or policy statement promoting the creation of some toolset, ...
$0.02...
-dmc Douglas McClendon
On 01/28/2014 08:03 PM, Douglas McClendon wrote:
On 01/28/2014 05:44 PM, Jim Perrin wrote:
On 01/28/2014 03:46 PM, Clint Savage wrote:
- Build or maintain tools to ease rebranding of upstream packages as to
ease adoption by companies who build upon and release software based on CentOS.
This would be useful, but could prove to be a Sisyphean task, given that new packages get added, packages get updated, etc.
To help others not do the legwork I did (from en.wiktionary.org://sisyphean)
"Sisyphus was a Greek mythological figure who was doomed to endlessly roll a boulder up a hill in Hades."
lol :)
Note, while I worked as Ascendos lead developer for some time, I'm speaking now just as a random individual with a past, and possibly future interest in rebuilding EL from source on a standalone system. Ideally a single outtermost wrapper script command. And ideally with a pair of arguments- a new distro name, and a new distro logo. And then, the right Sisyphean task completed by the tireless computer system with sufficient automating instructions.
To that end, I'd like to say that I think the 'sisyphean' comment doesn't fit my picture of where things are. My perception is that historically redhat has had a choice. A choice of making the task of rebranding drastically more or less sisyphean. While I haven't been paying that close attention the last couple years, the general feeling I get, is that they want to have a good reputation, and take the non-sisyphean track. Note, there are 2 different levels of rebranding here. One level, which I've been talking about, is complying with redhat on trademarks. The next level is complying with every last trademark holder in the distro. Dealing with this latter is/was perhaps my sisyphean task. Because ultimately what I wish to empower, is any and every single 10 year old computer wiz, being able to trivially have in front of them- every line of source of a massive distro like EL, and be able to modify any line of that source in any way they want, and with a totally tractable trivial minimal effort (15 minutes of active participation tops) be able to kick off a rebuild of their own forked distro, that they have full rights to redistribute as freely as they please. Getting there may be sisyphean, but I really think it is doable and worth doing.
But just dealing with the redhat/centos marks should be IMO a totally non-sisyphean a task. Given my estimation of redhat's intent and past actions on this are accurate. I.e, there is not so much effort with new and churning packages as I think you suggest. I posit that most of the trouble was with historical packages before people had really spent much time thinking about it. Am I wrong on that? Has the amount of Redhat->CentOS mark scrubbing not gone down dramatically v4->5->6->7 ?? Is it really a 'sisyphean task' to finally get it down to 0 with all marks-in-need-of-scrubbing only in a couple packages (redhat-logos, etc)?
- Providing tools to help monitor statuses of builds, repositories,
releases, etc. Whether they be part of the CentOS community or otherwise.
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
I like the idea, and the fact that it provides independent validation, but I'm not sure this fits with the idea of a SIG. The reason I say this is because for code in the sig/variant model, it needs to live on git.centos.org so that it could be built/signed by the project, which seems counter to the whole 3rd party validation this would provide.
I think there is a large area for build tools that are the 'blessed way' to build the source from scratch. 'blessed' by centos/redhat (are we allowed to utter that name more freely on the list these days?). But validated by others easily able to fetch them, audit the code and configuration to their hearts desire, and rebuild with or without enhancements of their own. Probably much of this already exists, I think the spirit of this topic is just committing to the whole of the picture. Commitment could come in the form of an ongoing SIG, or policy statement promoting the creation of some toolset, ...
$0.02...
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
The goal of this collaboration is to take the need to have other groups rebuild the same things over and over again away, and have people layer the things they want on top of what is already built, only adding the things that are new on top of the base that already exists.
They use the SIGs to bring in the things that need to be added in a separate git branch, then they spend their time adjusting their code that lives in parallel to the CentOS base. They then do not need to spend time redoing the same thing that CentOS is already doing.
CentOS provides a piece, the SIGs provide other pieces, that together provide the final compilation for that SIG ... that's the point of this endeavor. It is the whole point of the public build system for SIGs, etc.
On 01/28/2014 11:10 PM, Johnny Hughes wrote:
On 01/28/2014 08:03 PM, Douglas McClendon wrote:
On 01/28/2014 05:44 PM, Jim Perrin wrote:
On 01/28/2014 03:46 PM, Clint Savage wrote:
- Build or maintain tools to ease rebranding of upstream packages as to
ease adoption by companies who build upon and release software based on CentOS.
This would be useful, but could prove to be a Sisyphean task, given that new packages get added, packages get updated, etc.
To help others not do the legwork I did (from en.wiktionary.org://sisyphean)
"Sisyphus was a Greek mythological figure who was doomed to endlessly roll a boulder up a hill in Hades."
lol :)
Note, while I worked as Ascendos lead developer for some time, I'm speaking now just as a random individual with a past, and possibly future interest in rebuilding EL from source on a standalone system. Ideally a single outtermost wrapper script command. And ideally with a pair of arguments- a new distro name, and a new distro logo. And then, the right Sisyphean task completed by the tireless computer system with sufficient automating instructions.
To that end, I'd like to say that I think the 'sisyphean' comment doesn't fit my picture of where things are. My perception is that historically redhat has had a choice. A choice of making the task of rebranding drastically more or less sisyphean. While I haven't been paying that close attention the last couple years, the general feeling I get, is that they want to have a good reputation, and take the non-sisyphean track. Note, there are 2 different levels of rebranding here. One level, which I've been talking about, is complying with redhat on trademarks. The next level is complying with every last trademark holder in the distro. Dealing with this latter is/was perhaps my sisyphean task. Because ultimately what I wish to empower, is any and every single 10 year old computer wiz, being able to trivially have in front of them- every line of source of a massive distro like EL, and be able to modify any line of that source in any way they want, and with a totally tractable trivial minimal effort (15 minutes of active participation tops) be able to kick off a rebuild of their own forked distro, that they have full rights to redistribute as freely as they please. Getting there may be sisyphean, but I really think it is doable and worth doing.
But just dealing with the redhat/centos marks should be IMO a totally non-sisyphean a task. Given my estimation of redhat's intent and past actions on this are accurate. I.e, there is not so much effort with new and churning packages as I think you suggest. I posit that most of the trouble was with historical packages before people had really spent much time thinking about it. Am I wrong on that? Has the amount of Redhat->CentOS mark scrubbing not gone down dramatically v4->5->6->7 ?? Is it really a 'sisyphean task' to finally get it down to 0 with all marks-in-need-of-scrubbing only in a couple packages (redhat-logos, etc)?
- Providing tools to help monitor statuses of builds, repositories,
releases, etc. Whether they be part of the CentOS community or otherwise.
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
I like the idea, and the fact that it provides independent validation, but I'm not sure this fits with the idea of a SIG. The reason I say this is because for code in the sig/variant model, it needs to live on git.centos.org so that it could be built/signed by the project, which seems counter to the whole 3rd party validation this would provide.
I think there is a large area for build tools that are the 'blessed way' to build the source from scratch. 'blessed' by centos/redhat (are we allowed to utter that name more freely on the list these days?). But validated by others easily able to fetch them, audit the code and configuration to their hearts desire, and rebuild with or without enhancements of their own. Probably much of this already exists, I think the spirit of this topic is just committing to the whole of the picture. Commitment could come in the form of an ongoing SIG, or policy statement promoting the creation of some toolset, ...
$0.02...
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
My personal answer is about a 50/50 split between
a) ego stripping
I simply want to take advantage of open source software in that way. Replacing others marks with my own, but keeping all the same utility of the code. As easily/automated as possible, and helping others to be able to do so trivially as well.
b) distrust of others compilers and buildsystems
I would basically like an alternative to centos, that comes as 99% source, 1% binary, vs the current 50/50. It won't bother me if it takes a week of initial build time to replicate the binary portion on my home system.
I also believe putting a and b together will facilitate a more lubricated competitive open source ecosystem. I mentioned clearly the concept of lowering the bar to forking down to 15 minutes of childsplay.
The goal of this collaboration is to take the need to have other groups rebuild the same things over and over again away, and have people layer the things they want on top of what is already built, only adding the things that are new on top of the base that already exists.
Ok then, if the goal of the collaboration is indeed within the scope you described, and I agree what I described above is beyond that scope, then you have convinced me no SIG or policy change should happen. I hope others are more persuaded by the utility of what I described. Or perhaps Clint and Jim will find other common ground to discuss that I may personally be less interested in.
-dmc
They use the SIGs to bring in the things that need to be added in a separate git branch, then they spend their time adjusting their code that lives in parallel to the CentOS base. They then do not need to spend time redoing the same thing that CentOS is already doing.
CentOS provides a piece, the SIGs provide other pieces, that together provide the final compilation for that SIG ... that's the point of this endeavor. It is the whole point of the public build system for SIGs, etc.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Jan 28, 2014 at 10:10 PM, Johnny Hughes johnny@centos.org wrote:
On 01/28/2014 08:03 PM, Douglas McClendon wrote:
On 01/28/2014 05:44 PM, Jim Perrin wrote:
On 01/28/2014 03:46 PM, Clint Savage wrote:
- Build or maintain tools to ease rebranding of upstream packages as to
ease adoption by companies who build upon and release software based on CentOS.
This would be useful, but could prove to be a Sisyphean task, given that new packages get added, packages get updated, etc.
To help others not do the legwork I did (from en.wiktionary.org://sisyphean)
"Sisyphus was a Greek mythological figure who was doomed to endlessly roll a boulder up a hill in Hades."
lol :)
Note, while I worked as Ascendos lead developer for some time, I'm speaking now just as a random individual with a past, and possibly future interest in rebuilding EL from source on a standalone system. Ideally a single outtermost wrapper script command. And ideally with a pair of arguments- a new distro name, and a new distro logo. And then, the right Sisyphean task completed by the tireless computer system with sufficient automating instructions.
To that end, I'd like to say that I think the 'sisyphean' comment doesn't fit my picture of where things are. My perception is that historically redhat has had a choice. A choice of making the task of rebranding drastically more or less sisyphean. While I haven't been paying that close attention the last couple years, the general feeling I get, is that they want to have a good reputation, and take the non-sisyphean track. Note, there are 2 different levels of rebranding here. One level, which I've been talking about, is complying with redhat on trademarks. The next level is complying with every last trademark holder in the distro. Dealing with this latter is/was perhaps my sisyphean task. Because ultimately what I wish to empower, is any and every single 10 year old computer wiz, being able to trivially have in front of them- every line of source of a massive distro like EL, and be able to modify any line of that source in any way they want, and with a totally tractable trivial minimal effort (15 minutes of active participation tops) be able to kick off a rebuild of their own forked distro, that they have full rights to redistribute as freely as they please. Getting there may be sisyphean, but I really think it is doable and worth doing.
But just dealing with the redhat/centos marks should be IMO a totally non-sisyphean a task. Given my estimation of redhat's intent and past actions on this are accurate. I.e, there is not so much effort with new and churning packages as I think you suggest. I posit that most of the trouble was with historical packages before people had really spent much time thinking about it. Am I wrong on that? Has the amount of Redhat->CentOS mark scrubbing not gone down dramatically v4->5->6->7 ?? Is it really a 'sisyphean task' to finally get it down to 0 with all marks-in-need-of-scrubbing only in a couple packages (redhat-logos, etc)?
- Providing tools to help monitor statuses of builds, repositories,
releases, etc. Whether they be part of the CentOS community or
otherwise.
With these goals in mind, we'd like to formally request an
Interoperability
Special Interest Group within the CentOS community. Please let us know
how
to further proceed.
I like the idea, and the fact that it provides independent validation, but I'm not sure this fits with the idea of a SIG. The reason I say this is because for code in the sig/variant model, it needs to live on git.centos.org so that it could be built/signed by the project, which seems counter to the whole 3rd party validation this would provide.
I think there is a large area for build tools that are the 'blessed way' to build the source from scratch. 'blessed' by centos/redhat (are we allowed to utter that name more freely on the list these days?). But validated by others easily able to fetch them, audit the code and configuration to their hearts desire, and rebuild with or without enhancements of their own. Probably much of this already exists, I think the spirit of this topic is just committing to the whole of the picture. Commitment could come in the form of an ongoing SIG, or policy statement promoting the creation of some toolset, ...
$0.02...
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
I don't think the intent here is to rebuild the rebuilt code. It is to rebuild the upstream source in a similar way to the CentOS process. It might mean the source is distributed differently than its current state, but it should still be distributed.
The goal of this collaboration is to take the need to have other groups rebuild the same things over and over again away, and have people layer the things they want on top of what is already built, only adding the things that are new on top of the base that already exists.
They use the SIGs to bring in the things that need to be added in a separate git branch, then they spend their time adjusting their code that lives in parallel to the CentOS base. They then do not need to spend time redoing the same thing that CentOS is already doing.
The SIGs rely on a process managed by CentOS. Having that process reviewed and improved by an outside entity would seem like an ideal way to audit code, improve processes and be as open as possible. These things seem like benefits. I'm not sure why you would not want to have this in place.
CentOS provides a piece, the SIGs provide other pieces, that together provide the final compilation for that SIG ... that's the point of this endeavor. It is the whole point of the public build system for SIGs, etc.
Agreed. And I'm excited to see it. As I said to Jim above, we are excited to help in any way we can and would love to continue this discussion toward something that benefits both the CentOS community and ours.
Cheers,
herlo
On 01/29/2014 06:08 AM, Clint Savage wrote:
I don't think the intent here is to rebuild the rebuilt code. It is to rebuild the upstream source in a similar way to the CentOS process. It might mean the source is distributed differently than its current state, but it should still be distributed.
pointing to the redhat shipped faq: git.centos.org -> canonical source of public source release. There will be no ftp.redhat.com in the coming weeks/months; the first people will see source would be as a downstream of centos.
hence my question on why you want to work away from this process and limit yourself by design, rather than work within and for the process.
The SIGs rely on a process managed by CentOS. Having that process reviewed and improved by an outside entity would seem like an ideal way to audit code, improve processes and be as open as possible. These things seem like benefits. I'm not sure why you would not want to have this in place.
vendorisation and commercialisation within silo's - isnt that what we are trying to get away from ? so why go down the route of encouraging it by creating the -arguabally- whacked idea that communities are not just people working towards a goal ? Johnny mentioned it in his post as well, using different words, but let me re-iterate that ; given that we all might want to work towards the same goal, why not be a part of that process. I still dont see any value in people spending time on a process that effectively aims to find syntax errors in bash scripts. hopefully, there wont be any - since those bash scripts contribute to the code that gets shipped out.
Look it at another, more tangiable way: why fork a test harness when the harness and payload are easily contributed into, open ended.
Agreed. And I'm excited to see it. As I said to Jim above, we are excited to help in any way we can and would love to continue this discussion toward something that benefits both the CentOS community and ours.
Then step up, be a part of the process. help remove the US v/s THEM arguements. Surely being in a place where you can submit patches and fix issues > standing on the sidelines putting red cross's in the gutter column of git blames.
I acknowledge that I am widely trivialising the effort you propose, but I do so in order to highlight the fact that you dont need to do this as an outside entity or a SIG - just work with the scope of baseline content.
On Wed, Jan 29, 2014 at 4:39 AM, Karanbir Singh mail-lists@karan.orgwrote:
On 01/29/2014 06:08 AM, Clint Savage wrote:
I don't think the intent here is to rebuild the rebuilt code. It is to rebuild the upstream source in a similar way to the CentOS process. It might mean the source is distributed differently than its current state, but it should still be distributed.
pointing to the redhat shipped faq: git.centos.org -> canonical source of public source release. There will be no ftp.redhat.com in the coming weeks/months; the first people will see source would be as a downstream of centos.
hence my question on why you want to work away from this process and limit yourself by design, rather than work within and for the process.
Yes, I realized this was going to change. My question is really where is the code for all of the packages going to live? I know that the processes at GoOSe depend currently on SRPMS, will those be going away? If so, how will these packages look? I'd love to help suggest how this might look, but to date, I've seen no discussion about it. Though I haven't read everything that has come by in the centos-devel list.
So you ask why work 'away' from this process. I don't think we want to be separate, we want to be heavily involved in discussions and improving CentOS as much as anything else.
The SIGs rely on a process managed by CentOS. Having that process reviewed and improved by an outside entity would seem like an ideal way to audit code, improve processes and be as open as possible. These things seem like benefits. I'm not sure why you would not want to have this in place.
vendorisation and commercialisation within silo's - isnt that what we are trying to get away from ? so why go down the route of encouraging it by creating the -arguabally- whacked idea that communities are not just people working towards a goal ? Johnny mentioned it in his post as well, using different words, but let me re-iterate that ; given that we all might want to work towards the same goal, why not be a part of that process. I still dont see any value in people spending time on a process that effectively aims to find syntax errors in bash scripts. hopefully, there wont be any - since those bash scripts contribute to the code that gets shipped out.
Look it at another, more tangiable way: why fork a test harness when the harness and payload are easily contributed into, open ended.
Forking is important. If I don't fork your code, you don't get contributions back from me. How else would you propose we do this?
Agreed. And I'm excited to see it. As I said to Jim above, we are excited to help in any way we can and would love to continue this discussion toward something that benefits both the CentOS community and ours.
Then step up, be a part of the process. help remove the US v/s THEM arguements. Surely being in a place where you can submit patches and fix issues > standing on the sidelines putting red cross's in the gutter column of git blames.
I acknowledge that I am widely trivialising the effort you propose, but I do so in order to highlight the fact that you dont need to do this as an outside entity or a SIG - just work with the scope of baseline content.
KB, I appreciate your candor and I look forward to being a part of the process. The value of this is having an entity that is not just part of CentOS, but also has an outsiders view. We are stepping up as you say, we want to help. We've suggested several areas where CentOS and other EL rebuild communities, including ours could work together within your SIG definition to make things better for all.
-- Karanbir Singh
Cheers,
herlo
On Wed, Jan 29, 2014 at 5:39 AM, Karanbir Singh mail-lists@karan.org wrote:
vendorisation and commercialisation within silo's - isnt that what we are trying to get away from ?
While I agree with the practical aspects of centralizing everything, I don't see how you can use an argument against 'silos' to justify keeping everything in yours. There's no reason at this point to assume that any alternatives would be less open.
On 01/29/2014 03:57 PM, Les Mikesell wrote:
On Wed, Jan 29, 2014 at 5:39 AM, Karanbir Singh mail-lists@karan.org wrote:
vendorisation and commercialisation within silo's - isnt that what we are trying to get away from ?
While I agree with the practical aspects of centralizing everything, I don't see how you can use an argument against 'silos' to justify keeping everything in yours. There's no reason at this point to assume that any alternatives would be less open.
you are quoting me out of context and talking about alternatives as being complete alternatives. Both of those just sound like convenient assumptions to make a wrong point.
On 01/29/2014 06:10 AM, Johnny Hughes wrote:
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
The reason does not have to be to build public distro, or maybe public but for other purposes. One of the issues every user of CentOS is facing is security.
Reality is that CentOS rebuilds packages to be 100% binary compatible. That means rebuilding against specific versions of packages for dependencies. Essentially, you packages will have same security bug RHEL has, if that bug was created with manipulating environment. I read recently an article which explains how compiling first with modified compiler then with "proper"/vanila one can introduce changes in the way same code of the package will be binary different.
So first thing that comes to my mind is: If several persons inside Red Hat decide which environment will be created to build a package, is it possible those persons to be working with NSA to implant hardly detectable security holes? Even Read Hat CEO does not have to be aware of that. And if process is non-transparent and needs tweaking, then one can assume foul play is possible.
As a normal CentOS user, I do not really care much if my system has such sophisticated hole, but any foreign govt (not-USA) would have serious concerns to use something USA could have tampered with.
For example, Russian govt uses (as far as I remember) REL (Rosa Enterprise Linux). They are part of Russian govt FOSS Project, for use by all govt branches, just like RHEL is used by USA govt. What about other govts that distrust both USA and Russians?
And with recent claims that NSA is also running industrial espionage in favor of USA companies, Big international companies could be reluctant to use either RHEL or CentOS, or any other 100% binary clone.
Argument about USA govt using same packages does not have to be true. Since Red Hat has closed update/package network with accounts, how hard would it be to hook USA govt systems to slightly different channel with few key packages without bugs that exist for all other users of Red Hat? maybe just a active symlink creation pointing to secret packages.
That is why people might want to totally control building process without spending large amounts of time. Even if only to compare packages built against different environment.
On 01/29/2014 05:16 AM, Ljubomir Ljubojevic wrote:
On 01/29/2014 06:10 AM, Johnny Hughes wrote:
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
The reason does not have to be to build public distro, or maybe public but for other purposes. One of the issues every user of CentOS is facing is security.
Reality is that CentOS rebuilds packages to be 100% binary compatible. That means rebuilding against specific versions of packages for dependencies. Essentially, you packages will have same security bug RHEL has, if that bug was created with manipulating environment. I read recently an article which explains how compiling first with modified compiler then with "proper"/vanila one can introduce changes in the way same code of the package will be binary different.
So first thing that comes to my mind is: If several persons inside Red Hat decide which environment will be created to build a package, is it possible those persons to be working with NSA to implant hardly detectable security holes? Even Read Hat CEO does not have to be aware of that. And if process is non-transparent and needs tweaking, then one can assume foul play is possible.
As a normal CentOS user, I do not really care much if my system has such sophisticated hole, but any foreign govt (not-USA) would have serious concerns to use something USA could have tampered with.
For example, Russian govt uses (as far as I remember) REL (Rosa Enterprise Linux). They are part of Russian govt FOSS Project, for use by all govt branches, just like RHEL is used by USA govt. What about other govts that distrust both USA and Russians?
And with recent claims that NSA is also running industrial espionage in favor of USA companies, Big international companies could be reluctant to use either RHEL or CentOS, or any other 100% binary clone.
Argument about USA govt using same packages does not have to be true. Since Red Hat has closed update/package network with accounts, how hard would it be to hook USA govt systems to slightly different channel with few key packages without bugs that exist for all other users of Red Hat? maybe just a active symlink creation pointing to secret packages.
That is why people might want to totally control building process without spending large amounts of time. Even if only to compare packages built against different environment.
Well, it is very easy to see which SRPMs are modified and which ones are not (they will have a .centos in the name).
All the SRPMs are provided.
All the git trees (with logs) are provided.
All the binaries are provided.
All the mock configs will be provided.
All the build logs will be provided.
People will be able, if they choose, to check out any portion of the code and modify it on their own. Things with mods that are needed for SIGs can be pushed back into that SIGs tree and be part of the project.
CentOS will not be publishing RHEL packages directly, we will be publishing (like we do now) the things that come out of the build system ... which are tied to the build logs, root logs, and source code that will be published.
Everything will be available for public community review ... in fact, I would personally be suspicious of anyone who wanted to take the code and rebuild it OUTSIDE this openness, since all the source code, build logs, git tree history, etc, will not be available for that rebuild (or if it is available, then it is completely duplicated effort). Instead, if those people concentrate on what it is that they want to be different from the BASE, then anyone that wants to use what they produce, THAT IS DIFFERENT, can choose to get it. All of the community wins by getting more things that work with the EL code base ... rather than silos (or stovepipes) of things that are the same.
On 01/29/2014 07:17 AM, Johnny Hughes wrote:
On 01/29/2014 05:16 AM, Ljubomir Ljubojevic wrote:
On 01/29/2014 06:10 AM, Johnny Hughes wrote:
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
The reason does not have to be to build public distro, or maybe public but for other purposes. One of the issues every user of CentOS is facing is security.
Reality is that CentOS rebuilds packages to be 100% binary compatible. That means rebuilding against specific versions of packages for dependencies. Essentially, you packages will have same security bug RHEL has, if that bug was created with manipulating environment. I read recently an article which explains how compiling first with modified compiler then with "proper"/vanila one can introduce changes in the way same code of the package will be binary different.
So first thing that comes to my mind is: If several persons inside Red Hat decide which environment will be created to build a package, is it possible those persons to be working with NSA to implant hardly detectable security holes? Even Read Hat CEO does not have to be aware of that. And if process is non-transparent and needs tweaking, then one can assume foul play is possible.
As a normal CentOS user, I do not really care much if my system has such sophisticated hole, but any foreign govt (not-USA) would have serious concerns to use something USA could have tampered with.
For example, Russian govt uses (as far as I remember) REL (Rosa Enterprise Linux). They are part of Russian govt FOSS Project, for use by all govt branches, just like RHEL is used by USA govt. What about other govts that distrust both USA and Russians?
And with recent claims that NSA is also running industrial espionage in favor of USA companies, Big international companies could be reluctant to use either RHEL or CentOS, or any other 100% binary clone.
Argument about USA govt using same packages does not have to be true. Since Red Hat has closed update/package network with accounts, how hard would it be to hook USA govt systems to slightly different channel with few key packages without bugs that exist for all other users of Red Hat? maybe just a active symlink creation pointing to secret packages.
That is why people might want to totally control building process without spending large amounts of time. Even if only to compare packages built against different environment.
Well, it is very easy to see which SRPMs are modified and which ones are not (they will have a .centos in the name).
All the SRPMs are provided.
All the git trees (with logs) are provided.
All the binaries are provided.
All the mock configs will be provided.
All the build logs will be provided.
People will be able, if they choose, to check out any portion of the code and modify it on their own. Things with mods that are needed for SIGs can be pushed back into that SIGs tree and be part of the project.
CentOS will not be publishing RHEL packages directly, we will be publishing (like we do now) the things that come out of the build system ... which are tied to the build logs, root logs, and source code that will be published.
Everything will be available for public community review ... in fact, I would personally be suspicious of anyone who wanted to take the code and rebuild it OUTSIDE this openness, since all the source code, build logs, git tree history, etc, will not be available for that rebuild (or if it is available, then it is completely duplicated effort). Instead, if those people concentrate on what it is that they want to be different from the BASE, then anyone that wants to use what they produce, THAT IS DIFFERENT, can choose to get it. All of the community wins by getting more things that work with the EL code base ... rather than silos (or stovepipes) of things that are the same.
Let me take this just a bit further and give an example. Take a look at the "Cloud-init for CentOS" thread on this list recently. In that thread, several cloud providers for CentOS worked together with the maintainer of the common cloud-init package (in EPEL) and collaborated (just on this list and the final SIGs are not even complete yet) to get a package that works for several different groups available in a places that are not even part of CentOS.
How much easier will this process be once we have all the collaboration facilities in place?
Where else but here would all of those groups be working together to get a common package that works for all of the groups combined?
This is an example of how we can all win by getting groups out of stovepipes and silos and into community focused SIGs.
On 01/29/2014 02:26 PM, Johnny Hughes wrote:
On 01/29/2014 07:17 AM, Johnny Hughes wrote:
On 01/29/2014 05:16 AM, Ljubomir Ljubojevic wrote:
On 01/29/2014 06:10 AM, Johnny Hughes wrote:
If CentOS exists as a rebuild of the EL codebase and if the rebuilt code works and is tested by the community ... AND if the same source code can be used as the basis for the addon variant or repos seamlessly (as is our goal), then why does someone else need to rebuild the rebuilt code again under another name?
The reason does not have to be to build public distro, or maybe public but for other purposes. One of the issues every user of CentOS is facing is security.
Reality is that CentOS rebuilds packages to be 100% binary compatible. That means rebuilding against specific versions of packages for dependencies. Essentially, you packages will have same security bug RHEL has, if that bug was created with manipulating environment. I read recently an article which explains how compiling first with modified compiler then with "proper"/vanila one can introduce changes in the way same code of the package will be binary different.
So first thing that comes to my mind is: If several persons inside Red Hat decide which environment will be created to build a package, is it possible those persons to be working with NSA to implant hardly detectable security holes? Even Read Hat CEO does not have to be aware of that. And if process is non-transparent and needs tweaking, then one can assume foul play is possible.
As a normal CentOS user, I do not really care much if my system has such sophisticated hole, but any foreign govt (not-USA) would have serious concerns to use something USA could have tampered with.
For example, Russian govt uses (as far as I remember) REL (Rosa Enterprise Linux). They are part of Russian govt FOSS Project, for use by all govt branches, just like RHEL is used by USA govt. What about other govts that distrust both USA and Russians?
And with recent claims that NSA is also running industrial espionage in favor of USA companies, Big international companies could be reluctant to use either RHEL or CentOS, or any other 100% binary clone.
Argument about USA govt using same packages does not have to be true. Since Red Hat has closed update/package network with accounts, how hard would it be to hook USA govt systems to slightly different channel with few key packages without bugs that exist for all other users of Red Hat? maybe just a active symlink creation pointing to secret packages.
That is why people might want to totally control building process without spending large amounts of time. Even if only to compare packages built against different environment.
Well, it is very easy to see which SRPMs are modified and which ones are not (they will have a .centos in the name).
All the SRPMs are provided.
All the git trees (with logs) are provided.
All the binaries are provided.
All the mock configs will be provided.
All the build logs will be provided.
People will be able, if they choose, to check out any portion of the code and modify it on their own. Things with mods that are needed for SIGs can be pushed back into that SIGs tree and be part of the project.
CentOS will not be publishing RHEL packages directly, we will be publishing (like we do now) the things that come out of the build system ... which are tied to the build logs, root logs, and source code that will be published.
Everything will be available for public community review ... in fact, I would personally be suspicious of anyone who wanted to take the code and rebuild it OUTSIDE this openness, since all the source code, build logs, git tree history, etc, will not be available for that rebuild (or if it is available, then it is completely duplicated effort). Instead, if those people concentrate on what it is that they want to be different from the BASE, then anyone that wants to use what they produce, THAT IS DIFFERENT, can choose to get it. All of the community wins by getting more things that work with the EL code base ... rather than silos (or stovepipes) of things that are the same.
Let me take this just a bit further and give an example. Take a look at the "Cloud-init for CentOS" thread on this list recently. In that thread, several cloud providers for CentOS worked together with the maintainer of the common cloud-init package (in EPEL) and collaborated (just on this list and the final SIGs are not even complete yet) to get a package that works for several different groups available in a places that are not even part of CentOS.
How much easier will this process be once we have all the collaboration facilities in place?
Where else but here would all of those groups be working together to get a common package that works for all of the groups combined?
This is an example of how we can all win by getting groups out of stovepipes and silos and into community focused SIGs.
You misunderstood me.
I do get the proposed process, and it is a good one for add-on packages. What I focused on is packages from base that need to be 100% binary compatible, and only on those. And only in perspective of recreating the environment and POSSIBLE (I have not said probable) injection of security bugs. The document in question was: http://cm.bell-labs.com/who/ken/trust.html
All I argued is there IS POSSIBILITY for distrust and wish to build it by "yourself". Because if your job is to be paranoid, then YOU need to control the entire process.
I appreciate the feedback here. I'm going to go ahead and respond inline as I can.
On Tue, Jan 28, 2014 at 4:44 PM, Jim Perrin jperrin@centos.org wrote:
On 01/28/2014 03:46 PM, Clint Savage wrote:
One of the major values of the EL rebuild ecosystem is the ability to interoperate, or the ability to fork from the upstream. This provides purpose in many ways, choice being the most heralded. Since the CentOS community has teamed up with Red Hat to allow for Special Interest Groups to join them, it seems that there might be a bit less of an ecosystem available. The goal of the Interoperability SIG is to ensure that the ability to fork and rebuild still exist.
I consider one of the goals of the new arrangement to be creating more community, or ecosystem. However the way we've structured things so far will (hopefully) homogenize things a bit. I personally consider it a bit of a systemic failure that users have to hunt through any number of 3rd party repos to accomplish what they're after, often getting themselves into trouble in the process.
I wholeheartedly concur with the idea of what CentOS is trying to do here. Making things easy for people to accomplish their goals is also a bold one. One which CentOS and Red Hat are attempting. I truly hope they succeed. I'm a huge fan of the Fedora community that Red Hat contributes to in a much similar way. I think CentOS will be a great middle ground to help bring communities together. It should evolve into something amazing.
However, homogenizing things is a great idea, until it isn't. One of the common threads we hear in the Fedora community is that it's really run by Red Hat and nobody else gets a say. Many people, including myself, worry about CentOS being perceived this way as well. We just want to ensure that perception doesn't have any merit. If we provide a way to validate things are not just being run by RH, it could foster some goodwill everywhere.
Our communities already exist outside of the CentOS community purview.
They
are currently the GoOSe Project[1] and the Ascendos Project[2]. This
shared
community will serve as a "reference implementation", yet will still be operated and marketed as a product and community separate from CentOS. Consider it something of CentOS "embassy" of sorts.
It's been a stated goal from the beginning of the discussion (on both sides) that we have no 'collateral damage' to other groups who don't want to participate. For other builders, the only thing that should really change would be the location of the source they get.
Agreed. Though we don't know how that 'source' is going to look quite yet. I hope that srpms continue to live somewhere.
It would seem that this SIG could be construed as contrary to the goals
of
the CentOS project. However, we believe there is value added to the
CentOS
project. We are interested in improving the CentOS community in at least
a
few ways.
I don't see this as contrary, I see it as independent verification that we're living up to our stated objectives. It does however bring up a minor point of concern. For GoOSe, I only see a release for 6.0 on the download page, and no download option for Ascendos. I'd like some assurance that if your project steps up as a 'validation entity' that it won't falter. If we do this and it lags or dies off, that may reflect poorly on us (the project). It might be construed as either failing to live up to our goals, or intentionally killing it.
Yes, we did stagnate some on both ends. A hope was that some folks might join us to help. It is certainly possible for us to catch up on builds and such. Or we may just jump in validating EL7 and move back to 6.x as time permits.
- Providing feedback and collaboration on common issues. Including, but
not
limited to, reporting bugs, providing patches, discussing packaging techniques, rebuilding variants, QA, ISO building, etc.
Within the CentOS context or GoOSe? How are you proposing that we orchestrate the collaboration between the two?
That is a very good question. I think both groups would benefit. Initially, the plan is to file bugs on the CentOS side and track them within our community. However, i can see a possibility of some sort of middle ground where feedback comes in mailing lists, bugs, documentation and more.
- Collaboration on documentation of the rebuild process, rebranding of
documentation, providing new documentation, etc.
Same two questions.
We're planning on working on processes for rebranding and documenting the rebuild process. I see both of those things benefiting CentOS while the projects might be created elsewhere.
- Build or maintain tools to ease rebranding of upstream packages as to
ease adoption by companies who build upon and release software based on CentOS.
This would be useful, but could prove to be a Sisyphean task, given that new packages get added, packages get updated, etc.
Very true, I don't want to be pushing rocks uphill forever either. :) I think the value here is that a scrubbing service could be written. I kind of think of this like translation is currently done in some circles. You have some software go through each SRPM and see if it finds anything questionable and then have a human validate whether it is indeed needing some love. The process for this is not clear at this time, but I can see some options.
- Providing tools to help monitor statuses of builds, repositories,
releases, etc. Whether they be part of the CentOS community or otherwise.
With these goals in mind, we'd like to formally request an
Interoperability
Special Interest Group within the CentOS community. Please let us know
how
to further proceed.
I like the idea, and the fact that it provides independent validation, but I'm not sure this fits with the idea of a SIG. The reason I say this is because for code in the sig/variant model, it needs to live on git.centos.org so that it could be built/signed by the project, which seems counter to the whole 3rd party validation this would provide.
Because what you're proposing would live outside the structure and exist as an outside entity, does it make sense to be a SIG, or simply to have an understanding between groups?
I personally think it does fit as a SIG better than anywhere else at the moment, but it doesn't look like a SIG that has been outlined[1]. I do feel, however, it fits better in the lower end of that page where it is related to CentOS, provides control and feedback, all software created would be FOSS licensed, encourage the direction of the CentOS dev teams. In my mind, those are the goals we had and wanted to help there. We're not a variant, at least not in the same way the Cloud SIG would be.
I hope this helps to continue this discussion. Whether we end up becoming a CentOS SIG or not, we look forward to working with the CentOS teams.
Cheers,
herlo
1 - http://wiki.centos.org/SpecialInterestGroup
--
Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/28/2014 09:46 PM, Clint Savage wrote:
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
Couple of comments here, consider the in abstract:
1) everything you mentioned here, we already do and will only increase scope of
2) with the actual instance metadata in the public ( and on github! ) - there is very little cross-checking needed, since the result of the scripts is what gets published anyway ( and git log will history for anyone who cares ).
3) given the intention and direction for some of the points, duplicating effort also means diluting the single tooling effort - then at that point why would you not want to just contribute ( as people, not as projects ) into the common pool anyway ? ( ie. whats the justification for Goose to exist ? )
finally, not sure what makes this into a SIG, the content being addressed would be all in the public on git repos, so anyone can come along and 'help get better'.
- KB
On Wed, Jan 29, 2014 at 4:25 AM, Karanbir Singh kbsingh@centos.org wrote:
On 01/28/2014 09:46 PM, Clint Savage wrote:
With these goals in mind, we'd like to formally request an Interoperability Special Interest Group within the CentOS community. Please let us know how to further proceed.
Couple of comments here, consider the in abstract:
- everything you mentioned here, we already do and will only increase
scope of
Yep, and that is a good thing!
- with the actual instance metadata in the public ( and on github! ) -
there is very little cross-checking needed, since the result of the scripts is what gets published anyway ( and git log will history for anyone who cares ).
This sounds very open and grand. To this end, what is the harm in allowing us to improve upon what you have? Seems like a SIG that audits processes and documents things along the way could be even more valuable.
- given the intention and direction for some of the points, duplicating
effort also means diluting the single tooling effort - then at that point why would you not want to just contribute ( as people, not as projects ) into the common pool anyway ? ( ie. whats the justification for Goose to exist ? )
Let me give an actual example. Mathiew Bridon (bochecha) wrote a really cool monitoring tool called uptrack[1]. This tool resides outside of the CentOS community. The GoOSe project started to use this tool recently to monitor build status. Additional features have already been discussed and I have an intention of digging in and adding a few more. In my mind, this project could be used across both projects. I'm not sure exactly how an existing tool, uptrack, koji, mock, etc. would be considered part of the CentOS project just because they are using the tools it provides. To that end, we aren't necessarily duplicating certain efforts in writing tools that would help many EL rebuild communities.
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.
finally, not sure what makes this into a SIG, the content being addressed would be all in the public on git repos, so anyone can come along and 'help get better'.
Very true. It just seems a formalized effort would be better than no effort. Don't you agree?
- KB
Cheers,
herlo
-----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
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
-
Clint Savage -
Douglas McClendon -
Jim Perrin -
Johnny Hughes -
Karanbir Singh -
Karanbir Singh -
Karsten Wade -
Les Mikesell -
Ljubomir Ljubojevic -
Shawn Thompson