Mailinglist Archive: opensuse-factory (1029 mails)

< Previous Next >
Re: [opensuse-factory] O Factory - Where art Thou?
Stephan,

Thanks a lot for sharing your thoughts with us.


Quoting Stephan Kulow <coolo@xxxxxxx>:

Hi

But first let me give you some background, that you might not be aware
of: 10.3 had 3334 packages, 11.1 3746, 3605 for 11.2, 3807 for 11.3,
4784 in 12.1, 5710 in 12.2, 6246 in 12.3, 6678 in 13.1, 6800 right now
in Factory. If you need a picture, look at http://s.kulow.org/packages

impressive... And we're talking source packages here, not binary packages.

https://progress.opensuse.org/workflow/factory-proposal.html

We basically want to put the pressure on the submitting packager not the
user. Using factory should be safe, for this we want to revive a thing
that has been lost on the way: Bernhard's factory-tested project.

That looks interesting.. with two, for me, undefined 'dark processes' with huge impact:

- Needs staging?
- Needs QA?

Are there already ideas on how to implement/formulate this decision tree?

And we want to open another submission path: from staging projects.
Consider a situation where recent updates to GNOME and automake
'clash', causing problems when they're installed together. Right now we
throw both into Factory, breaking both for our Factory users until
we solve the issues. Instead, we think working on these issues in a
separate 'staging project' could be the solution. None of us knows how
*exactly* it will look alike because we need to get a conversation with
the OBS team going. But the basic idea is:

ok, I think THAT partially answers above question with a 'no'

- GNOME:Factory stays the devel project of things that relate to
GNOME updates
- devel:tools stays the devel project of things that relate to
automake updates
- on automake updates, we open up a new devel project that stages
GNOME packages for the new automake. In there, GNOME devs and
automake experts work together to fix them and updates in there
are submitted either back to GNOME:Factory and are integrated right
into Factory. Or if that's not possible, the automake update is
"grouped" with various GNOME package updates and these updates end
in Factory together.

In some cases, those breakages are easy identified.. in others, they are not. Staying with the GNOME examples (where I happen to also have some good insight): once G:F is being submitted to Factory, it is known to work on top of what is Factory 'at that moment' There are very few submits 'auto forwarded' (the team decides that on a case-by-case.. usually stable dot releases are considered safe to forward)

But as you say, an 'incoming automake' at the same time would of course 'change' what underlying Factory was, potentially break it (automake upgrades are known for that and well in our minds).

so, in this case, I'd consider 'automake' to be the critical component asking for staging.

But what in other cases, where it's less obvious? Like GLIB 2.32 (back in the days) when the 'include' style was changed to 'force' devs to do what upstream originally intended: only #include <glib/glib.h>, no other headers.

Inside G:Factory this was obviously sorted out prior to submission to Factory. And I believe we worked well enough in identifying the problem of this, knowing that other stuff relies heavily on glib, triggering a staging project (where I myself fixed a bunch of packages myself).

What though, if we'd not have identified this 'subtle' change as critical? Who would be responsible to 'detect' such things? (ok, let's not do a RACI for that.. latest with 'A' we will fail to assign this to anybody).

So far it's in 'trying' to detect those cases early enough, Stephan does a great job in this, his endless experience is a great asset for him being able to do so.

Also, we need to be able to define an exit trigger from a staging project: when do we consider it 'ready'. This does not forcibly mean 100% 'builds' against the offending package (imho), as this could potentially block a kernel from entering due to some low-hanging fruit just not having support for that kernel.. critical for the users of that module, sure, but critical enough to block a kernel update?

(just to show, this is not black/white magic.. and describing this in a way that it's clear and not 'subject to the mood of Stephan' is difficult, but should be a goal to strive for).

Dominique

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

< Previous Next >
Follow Ups
References