[CentOS-devel] CentOS Interoperability SIG
Douglas McClendon
dmc.centos at filteredperception.org
Wed Jan 29 05:47:47 UTC 2014
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 at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>
More information about the CentOS-devel
mailing list