[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