CentOS - Jun 2020 - Blog article about the state of CentOS

On 22/06/20 7:03 am, John Pierce wrote:
> On Sun, Jun 21, 2020 at 2:01 AM Simon Matter via CentOS <centos at
centos.org>
> wrote:
> 
>>> On 21/06/20 1:23 pm, John Pierce wrote:
>>>> but the build process should be the same, no?    I can't
believe RH
>>>> would
>>>> use a completely different build process for the release than
for the
>>>> beta/development stuff.
>>>
>>> The packages still have to be built as a whole, they need to go
through
>>> QA testing, isos need to be built and tested.  The only thing that
I can
>>> think of that Stream benefits this process is to help Red Hat find
the
>>> odd bug here and there before their final release (after which
CentOS
>>> still has to do everything listed above).
>>
>> As I understand it the whole full build and QA and whatever may still
be
>> done again. The big difference is that the whole work of how to build
and
>> setting up the build infrastructure has already been done and is known
and
>> tested. So the complete build is going quite fast and the big delays
are a
>> thing of the past.
>>
>> If it's going to be like that it sounds very good.
>>
> exactly, that was my point.    I remember 8.0 was very delayed by how much
> harder and different the build process was.
That work was completed in the build of 8.0 and to a smaller extent 8.1. 
  Stream doesn't really add anything here.


Peter

On Sun, 21 Jun 2020 at 15:10, Peter <peter at pajamian.dhs.org>
wrote:
>
> On 22/06/20 7:03 am, John Pierce wrote:
> > On Sun, Jun 21, 2020 at 2:01 AM Simon Matter via CentOS <centos at
centos.org>
> > wrote:
> >
> > exactly, that was my point.    I remember 8.0 was very delayed by how
much
> > harder and different the build process was.
>
> That work was completed in the build of 8.0 and to a smaller extent 8.1.
>   Stream doesn't really add anything here.
>
There are 2 sets of work.
1. There is the work on the tools which were slapped together as an
emergency from parts before 8.0. Those mbboxx tools are getting a
rewrite and upgrade currently by the CPE team to make them more useful
in the future. Stream only helps in that it is the excuse for that
work to be done versus it molding and falling apart right after every
8.x release comes out.
2. There is the work that happens because various things are rebased
and you need to figure out the HTF you get from build A to build A+1
by rebuilding N packages. That is work that Stream should help on
because this is then knowledge is being done in stream before hand. If
you know that package A went to A+1 then to A+2 and then back to A+1
but you learned how to do the second A+1 from a flag you used with
A+2, then the amount of time reinventing the wheel is shortened.
>
> Peter
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos


-- 
Stephen J Smoogen.

On 22/06/20 10:13 am, Stephen John Smoogen wrote:
> There are 2 sets of work.
> 1. There is the work on the tools which were slapped together as an
> emergency from parts before 8.0. Those mbboxx tools are getting a
> rewrite and upgrade currently by the CPE team to make them more useful
> in the future. Stream only helps in that it is the excuse for that
> work to be done versus it molding and falling apart right after every
> 8.x release comes out.
I didn't know that a rewrite is still needed on the current tool set and 
granted Stream can help with this, but I hardly think that it's 
necessary and the tool set can always be tested against the current 
release (8.2) from git.
> 2. There is the work that happens because various things are rebased
> and you need to figure out the HTF you get from build A to build A+1
> by rebuilding N packages. That is work that Stream should help on
> because this is then knowledge is being done in stream before hand. If
> you know that package A went to A+1 then to A+2 and then back to A+1
> but you learned how to do the second A+1 from a flag you used with
> A+2, then the amount of time reinventing the wheel is shortened.
This I do realize and it's the one exception I considered where Stream 
might come in handy, but not handy enough to justify its existence, imo. 
  Usually in a new point release there might be a small handful of 
packages that need re-basing, out of those the number of packages that 
would need to have the spec file tweaked to build them would be minimal 
(at a complete guess three or less) and out of those the number that 
would require a change to the tool set would likely average out to be 
less than one per point release.  In a worst-case scenario it might save 
a day or two on a particularly nasty point release, and this would 
easily be recouped in the amount of time it would save if the CentOS 
team did not have to maintain Stream at all.

Now these are just semi-educated guesses and I don't have the experience 
to justify this so I'm happy to consider real numbers that prove me wrong.


Peter