[CentOS-devel] CentOS Interoperability SIG

[Clint Savage]

On Tue, Jan 28, 2014 at 10:10 PM, Johnny Hughes <johnny at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140128/b61b9617/attachment.html>