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.