Use Update channels when adding distributions

[scarabeusiv]

Issue Description

When adding new repositories from UI (adding new distribution) by default it adds the GA channels. As a Leap example:

 <repository name="openSUSE_Leap_15.0">
    <path project="openSUSE:Leap:15.0" repository="standard"/>
    <arch>x86_64</arch>
  </repository>

The issue stands that with the new modular SLE strucutre we update a lot during the product lifecycle and users later complain that the OBS does not build what they are expecting to get because their repos are pointing to :GA channels (or for openSUSE the ones without :Update).

Of course workaround is to edit the metadata afterwards, but most people are not aware of this issue until it bites them.

Expected Result

When adding the Leap 15.0 distribution the metadata should contain:

 <repository name="openSUSE_Leap_15.0">
    <path project="openSUSE:Leap:15.0:Update" repository="standard"/>
    <arch>x86_64</arch>
  </repository>

How to Reproduce

1. Go to the add repository page, ie: https://build.opensuse.org/project/add_repository_from_default_list/home:scarabeus_iv
2. Click on 'Add from distribution'
3. Select desired distros.
4. List metadata and observe the issue with GA being added instead of Update.

[adrianschroeter]

On Montag, 1. Juli 2019, 09:45:02 UTC Tomáš Chvátal wrote:

Issue Description

When adding new repositories from UI (adding new distribution) by default it adds the GA channels. As a Leap example:

This is on purpose to keep build load low, no reason to rebuild, since updates must stay compatible.

However, only backward compatible, but you may break against GA packages when you build against update ....

 <repository name="openSUSE_Leap_15.0">
    <path project="openSUSE:Leap:15.0" repository="standard"/>
    <arch>x86_64</arch>
  </repository>

The issue stands that with the new modular SLE strucutre we update a lot during the product lifecycle and users later complain that the OBS does not build what they are expecting to get because their repos are pointing to :GA channels (or for openSUSE the ones without :Update).

well, if there is an update which breaks compability it is considered to be a bug in update ...

Of course workaround is to edit the metadata afterwards, but most people are not aware of this issue until it bites them.

Expected Result

When adding the Leap 15.0 distribution the metadata should contain:

 <repository name="openSUSE_Leap_15.0">
    <path project="openSUSE:Leap:15.0:Update" repository="standard"/>
    <arch>x86_64</arch>
  </repository>

How to Reproduce

1. Go to the add repository page, ie:

https://build.opensuse.org/project/add_repository_from_default_list/home:sc arabeus_iv 2. Click on 'Add from distribution'

3. Select desired distros.
4. List metadata and observe the issue with GA being added instead of Update.

--

Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de

[coolo]

Well, breaking compatilbity is not what this is about - this is about introducing new features in life cycle. If you believe, that our products only release 100% feature and bug compatible updates, you obviously slept the last 10 years.

[coolo]

What makes this whole thing an absolute user horror story btw: braching 15.0 packages branches from 15.0 update.

[adrianschroeter]

I never said feature or bug compatible. But it is the exception that you need a maintenance update to build your package.

And if your package breaks due to a maintenance update it is definitive a problem in the maintenance update.

[coolo]

You're looking from the wrong angle. Noone complains about updates breaking packages - they're complaining that they can't build packages for the 15.0 they use. And they do use the Qt or the python packages or the whatnot that is in :Update - and take it as fact: they are different than what is in :GA. They are compatible to GA, but they are not GA. And if that update happened for the exact reason to be in compliance with Factory sources, you're doomed.

And while adapting the repos isn't hard for you and @scarabeusiv it's a real challenge to regular users like David F trying to patch kmail. It's most often small details like rpm macros that ended up in the latest KDE update, but it's a problem.

And optimizing the OBS experience towards less build power sounds a little strange to me - as I explained earlier: if the Deutsche Post would stop carrying other people's letters, they would be more efficient as well.

If updates triggering too many rebuilds, perhaps considering the default rebuild mode is on the agenda. Different topic though.

[scarabeusiv]

@adrianschroeter the maintenance ECO updates do exactly this, it changes feature scope of our products. And with modules we are updating even more. Esp with caasp/cloud we do massive version updates and GA does not equal to what you are getting elsewhere. As such whatever you build on the GA only might not work in the end (it should, but might not).

If we do not have the resources to do the updates then we should change the rebuild strategy, because lets be honest all the develprjs I just checked are using :Update channels because it is useless otherwise and the spike with home prjs doing the same should not be so impactful...

[adrianschroeter]

this not about to be able to do updates. fresh branches and maintenance incidents of course always build against released updates.

This is about the third party devel project default setup. Every maintenance release will create plenty of events in any case, so it will increase the load on the schedulers which are already a bottleneck. And in addition very most builds will be unnecessary. The exception, where you really need a new feature of maintenance tree should also be the cases who opt in for it.

[adrianschroeter]

just to give you a number, we save about 4500 repository eveluations (direct, will be more if take indirect into account) for each maintenance release on x86_64 by default. We may not be able to finish low prio events on weekends anymore.