[CentOS-devel] Balancing the needs around the RHEL platform

On Fri, Jan 22, 2021 at 6:26 PM Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>
> On 1/22/21 4:53 PM, Brian (bex) Exelbierd wrote:
> > On Thu, Jan 21, 2021 at 12:16 PM redbaronbrowser via CentOS-devel
> >> Do they get a louder voice for paying the bills?
> >
> > Red Hat's louder voice is based on two different components.  The
> > primary form of this "louder voice" is that Red Hat employs a ton of
> > engineers who contribute directly to the CentOS Project or the
> > codebases that become elements of CentOS Project outputs.  We speak
> > loudly in the sense that we can choose what we do and what we don't
> > do.  In the same way committers in a project have a louder voice than
> > other contributors as they decide what the project will and will not
> > do.  This is the way Open Source works.
> >
> There is a silver lining here because at least few people offered to be
> active in producing CentOS, but were refused for various reasons. What I
> understood from those exchanges, main reason was CentOS dev team did not
> want anyone else to know how they are doing things, they wanted tight
> control. Even requests dev teams publish how they produce CentOS was
> refused. I never said anything because it did not affect me.

Red Hat also didn't say anything here because it didn't affect it's
needs, the same as you.  We wanted a development platform for the SIG
and other layered work.  This is part of the cognitive dissonance we
maintain with communities we sponsor.  In general we leave a community
alone to self-govern.  We only act as a company when we need to
protect the community and by extension the company from liabilities or
when our direct contribution goals are impacted. In the first case we
use positions like the Liaison to talk to the governing body and if
required (and it NEVER has been so far) our veto.  In the second case
we show up and make our case in the various bodies that manage the
code.  You can see this mostly in CentOS SIGs or in Fedora because
CentOS Linux was a rebuild and generally did not make or accept
changes that weren't in the code RHEL had published.

Now that we are all working on CentOS Stream there are some competing
interests in play when it comes to build systems, but I think that
ultimately we will have more access and transparency.  WARNING: I am
not a distribution build engineer so I am speaking in generalities
here.

Our build systems and software has, in some cases, not changed to keep
up with modern development practices or needs.  Does this make it bad
or wrong? No.  Does it offer room for improvement? Absolutely.
Looking at some of the work individual contributors have done to align
build processes and software across distributions and third-party
repos, I think that it is exciting to be able to use CentOS Stream as
a platform for thinking about our entire build process.  This won't be
fast or easy as we have to be very careful, but it should be possible
in a way that CentOS couldn't before.  This is possible explicitly
because CentOS now is ahead of RHEL, not behind it.  It is building
tomorrow, not rebuilding yesterday.

The other interest though is around the actual act of making the
distribution, the "turning of the crank."  Here Red Hat has very
specific security interests and we need to limit the ability to do
specific build tasks to specific people.  Having spoken to the CPE
team, the engineering organization in Red Hat that is tasked with our
infrastructure contribution to CentOS, I know they are looking at
every option to open up what they can.  One thing they have to do is
to get new authentication and other practices in place, which CentOS
has traditionally not had in this fashion, to allow the right access
(again - I am speaking in generalities here and glossing over detail.
Detail discussions are not going to be useful if I am participating
:D).  They will tell you that in internal meetings I am constantly
harping on the need to get SIGs greater controls and build
opportunities, for example.  That internal meetings comment raises a
great question around how to get more community participation.  There
is an infrastructure SIG spinning up to ensure that there is a forum
for these conversations.  I'd also love to see, if we can technically
do it, a SIG focused on improving build systems, with an eye toward
making the deliberate incremental change that lifts all of us (Fedora,
CentOS, RHEL, EPEL. elrepo, etc.).

>
> So this is a case of  "secretive group" deciding and controlling entire
> project and naturally anyone else had no say in what is done beyond
> proposing something on the mailing list or forums and hoping group in
> control will accept their reasoning.
>
> Again, as far as I got the no-cost distro I was fine with how it was
> run, but saying anyone else could have a say/voice is false.

AIUI, the way the CentOS Linux distribution is produced as a direct
artifact, your statement is generally true.  I suspect this was
largely driven by the rebuild nature of CentOS Linux and the fact that
the engineering the project did was almost exclusively in service
rebuilding, not creating software.  An opportunity we have, as a
community, is to really embrace the full definition of contribution.
If you look at Fedora, as an example, we have lots of contributors who
have never written a line of code or packaged a piece of software.
Their contribution is invaluable and important.  CentOS can have that
too, if it wants it.  I hope that this will be another area where the
community shows up and the project thrives.  Innovation comes in many
forms, let's go find the ones we want to tackle, whether code or
non-code activities.

regards,

bex