Mailinglist Archive: opensuse-factory (1134 mails)

< Previous Next >
Re: [opensuse-factory] Calling for a new openSUSE development model
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Thu, 14 Jun 2012 21:19:14 +0200
  • Message-id: <7623002.Z15kbaB8C1@scherben>
Am Donnerstag, 14. Juni 2012, 21:01:27 schrieb Adrian Schröter:
Am Donnerstag, 14. Juni 2012, 20:16:37 schrieb Stephan Kulow:
Am 14.06.2012 19:59, schrieb Adrian Schröter:

gcc is really very special, Richard is already doing test builds of
entire Factory
in his own project and I think this going to stay for first testing.

However, afterwards :Staging would define the next transaction to be
checked into Factory.

That can be either a really deep change (like gcc + last package fixes to
be on 100% green again),
but it could be also a step were only leaf packages or packages which
should have less impact.
The later case should be faster to test since way less packages need to
be build.

However, it would be up to the release manager/team to define this step.
Maybe we would need something
like a "LATER" functionality for requests then, if something is general
okay, but not for this step.
That still is not good enough for me to understand what you mean. A
transaction is what? a bunch of submit requests?

basically every package in :Staging would be submitted to Factory and :Staging
would be empty again afterwards.

So devel projects would stay, but SR to :Staging and from there we copy
it when what happend?

When we say :Staging is okay. No package failing, everything green. Or we say
we take some packages for this transaction.

I guess what I don't understand: how is having everything in one
:staging an advantage over having everything
in :Factory? I can revert single broken packages right now too - once I
understand where the problem comes from.
The problem is how to fix the problem - if the ruby update only breaks
devel:languages:ruby, but not the packages
in let's say system:management - unless ruby ends up in factory.

hm, that would mean that deeper packages can only be added to :Staging alone
and you need to wait until everything inside depending on it has finished.

I think you will point out now that this may take too long so you need
multiple
:Staging in parallel (and the build power for it).

A side note, what I do see here as well is that we may should go back to
entire
clean builds at least in these :Staging projects instead only the packages
with source changes ...

Just to draw a picture, such transactions could be similar to what we do
with maintenance updates. There could be

openSUSE:Factory:Staging:<number>

projects. realease managers would sort the submit requests into them.
For example

openSUSE:Factory:Staging:103
is just for binutils & gcc update. It is currently building all factory
packages to see if it has an effect.

openSUSE:Factory:Staging:104
contains random leaf packages. not much changed, but you still wait for
live cd builds to see if the new packages may make them to big.

openSUSE:Factory:Staging:105
got an KDE 4.99 update plus some qt packages. Build is finished, everything
fine. Could be merged into openSUSE:Factory.

We could even do it similar with maintenance and just move source and binaries
(with re-signing), so we would avoid extra builds.

It does not matter in which order these projects get merged. But after one
got merged the others may need to rebuild. So we should not get too many in
parallel ...

--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx

--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
This Thread