[CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting]

On Sat, 11 Jan 2020 at 16:57, Gordon Messmer <gordon.messmer at gmail.com> wrote:
>
> On 1/11/20 1:12 PM, Brian Stinson wrote:
> > I think the pattern is different with CentOS Linux though. There isn't really much 'contribution' to be done because the idea is to match what comes from RHEL sources as closely as possible. We don't have individual package maintainers in CentOS because 99% of the time we can get builds through
>
>
> I think the frustrating thing about CentOS is that when users ask why
> delays are so long, the maintainers say "producing CentOS is't just a
> matter of rebuilding Red Hat sources" and when users ask why there isn't
> a process to contribute the maintainers say "we're just rebuilding Red
> Hat sources, and we don't need help with that."
>

I think that the problem is that re-building an OS is a very very
complicated problem and everyone doesn't expect it to be. The only way
I have found to get a real idea of the amount of work is to actually
set up your own build system and go through what is needed to rebuild
the OS during the X.0 -> X.4 stage. You can get some set of packages
built without problems and then you find that they don't have some
feature that was expected. Then you have to work out the reorder of
the builds to get that feature in the various tools. Then you figure
out that you need to actually build the OS in multiple steps:

1. Take X.Y-1 and rebuild some of the packages from X.Y
2. Rebuild some of X-Y.1+new packages with that.
3. Rebuild X.Y packages with the set
4. Find out that a buildroot package (a package which isn't shipped by
Red Hat but used to build the OS) isn't working. Figure out that they
used a different version than what you have.
5. Go through that package docs and figure out which version/patch you
did or did not need.
6. Rebuild X.Y packages
7. Re order some of the builds (but not all of them) and rebuild a couple more
8. Rebuild more of X.Y
9. Make a compose
10. Find out that the compose fails because X.Y used some new features.
11. Go back to 3 with a couple of other items.

After a couple of iterations you get an OS working and the QA people
can do installs. There they find that something was wrong in X.Y-1
which causes updates to X.Y to break. Come up with new package fixes
for that.

Spend each day getting pinged at least 3*Ndays (since X.Y release)
times on IRC, personal email and mailing lists by users wanting to
know why they can't update to the latest package yet.

At times you will try giving out some packages before you have the
entire compose, and then find out that email is flooded with broken
systems which needed some soft dependency you haven't gotten done yet.
Or you might think you got all of them and find out that you had to go
back to 3 but someone who put X.Y-beta in production on 4000 servers
is spamming every list about how your OS is crap... and lots of people
add on to it that they found the software was broken too. [You might
get some people who point out that it was not ready and then you get
slammed with people saying if it wasn't ready why did you even let
anyone get it.]

Pretty much everyone I know who has done a rebuild of RHEL or CentOS
or the clone of CentOS they found.. ends up finding this is what a
release is like.




-- 
Stephen J Smoogen.