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

On Thu, Dec 24, 2020 at 7:49 PM Konstantin Boyandin via CentOS-devel <
centos-devel at centos.org> wrote:

> On 25.12.2020 08:05, Mike McGrath wrote:
> > On Thu, Dec 24, 2020 at 3:59 PM redbaronbrowser via CentOS-devel
> > <centos-devel at centos.org <mailto:centos-devel at centos.org>> wrote:
> >      > At that point, is the question you're asking whether or not the
> >     CentOS
> >      > kernel should be a rebuild of an RHEL kernel SRPM?  These don't
>  seem
> >      > like questions that the CentOS maintainers would have ever even
> >     accepted
> >      > for consideration.
> >
> >     In normal times, I wouldn't think of suggesting this.
> >
> >     The year of 2020 is clearly not normal times.
> >
> >     CentOS Stream is a new age.  We are the upstream now.  We should be
> >     able to choose the kernel and the quality level of the SRPM.
> >
> >     I believe what makes something CentOS is the governance.
> >
> >     Red Hat's behavior makes it clear they believe what make something
> >     CentOS is who owns the trademark.  That they can lie about the
> >     governance rules to get whatever they want.
> >
> >     This militant attitude on the part of Red Hat and the fraudulent
> >     governance board deserves an equally militant response.
> >
> >     Time fix the openness gap for the kernel SRPM for real instead of
> >     blindly following Karsten Wade's empty posturing in the name of
> >     openness.
> >
> >     Let's also fix the availability gap.  Karsten Wade vision for CentOS
> >     Stream is that 95% is good enough.  For every 1 million users there
> >     are 50,000 that have their needs fall through the cracks.  I think
> >     as a community we can provide better results than that.
> >
> >     Both openness gap and availability gap are worthy things to fix so
> >     let's fix them.  But Karsten Wade isn't offering an effective fix
> >     for those issues.
> >
> >
> > I agree with you the governance model needs work.  You've called out
> > Karsten a couple of times but it's not clear to me what his role is
> > going to be for CentOS Stream going forward.  That is to say, there are
> > others also involved in CentOS so you may not want to single him out.
> >
> > There are a few boundaries I know Red Hat would like to keep in place.
> >
> > 1) The mainline branch *is* RHEL and so anything that gets committed
> > there must be merged by a Red Hatter.
> >
> > 2) No attempting to do another downstream rebuild (for those that
> > desperately want to contribute to this, there are already other
> > communities for it and we won't be competing with them)
> >
> > 3) We want a robust SIG community, and that includes welcoming things
> > that Red Hat isn't particularly interested in.  So when we say no to
> > something in the mainline branch, SIGs should be a fairly safe place to
> > do that where they can use official build infrastructure and
> > distribution mirrors.  I've heard many people talk about special kernel
> > needs, enabling older hardware, kabi, etc.  I'd love to see that done in
> > a SIG.  I also personally think the bar for starting a SIG should be low.
>
> An interesting question here. CentOS Linux was free to use. Can you
> explicitly tell whether these SIGs should be related to paid-only
> services of RH?
>
> Or perhaps I can't see how that can be possible with CentOS Stream.
>
>
I'm going to be cautious about not writing policy here, that's for others
to do.  I will say that we've discussed several straw-man scenarios and
they all seemed to go ok to us at Red Hat.  As people have actual requests
let's work through them (though perhaps we should first figure out a
process for doing that...)

Examples (not to be taken as law, again I'm not a policymaker in CentOS but
can speak to some things that we've discussed over the last year as part of
potential Stream scenarios):

We know Facebook is taking CentOS Stream right now, adding whatever magic
they want to add, and are using it.  If they wanted to do that in a CentOS
SIG, and find others who want to do it with them.  We're good with that.
In fact, that sounds kind of cool to me.

Another one we discussed was forking of packages.  I forget what the rules
are in something like EPEL or even current CentOS SIGs.  But if someone
wants to maintain a fork or a new package that is of no value to Red Hat
and is not legally encumbered in some way, I think they should be allowed
to do that in CentOS Stream.

More to your point, if someone wants to build something on/for CentOS
Stream, that is never intended for RHEL nor any of Red Hat's products.  I
don't think Red Hat would have a problem with that.

If someone wanted to do something in a CentOS SIG, that had nothing to do
with even CentOS Stream, nor any of Red Hat's products, I'm not sure why
they'd come to CentOS with that request, but even that would be worth at
least discussing with someone.  The board maybe?  We should figure that out.



> > I'm not in the governance game here but the question for you, and
> > others, is this - What sort of governance model can we put in place to
> > accomplish these goals as well as whatever common goals we have going
> > forward?  What are our common goals from here?  I've seen many technical
>
> > issues brought up on the list over the last two weeks that seem solvable
> > to me.
>
> I am sure there will be answers.
>
> But, as far as I see, these questions should have been asked *before*
> the decision to bury CentOS Linux alive was taken and announced.
>
> (so much for openness and good communication, eh?)
>
>
I hope I'm wrong, and would love someone in the community or in Red Hat to
chime in here and correct me.... but I hope "what are our common goals" is
a question that has been asked at least sometime in the last several
years.  If not, let's correct that now.

         -Mike


> --
> Sincerely,
>
> Konstantin Boyandin
> system administrator (ProWide Labs Ltd. - IPHost Network Monitor)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201224/a3299b4a/attachment.html>