[CentOS-devel] CentOS Interoperability SIG

Wed Jan 29 05:10:42 UTC 2014
Johnny Hughes <johnny at centos.org>

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.



 





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140128/3c839eea/attachment-0005.sig>