#452 change inheritance of rawhide from the branched tree
Closed None Opened 10 years ago by notting.

= Proposal topic =

Currently, rawhide only inherits packages from the previous branched stable tree.
It has been proposed that we change this.

= Overview =

Right now, if I build a package for F-14, it ends up in the updates-candidate repo, which is not pushed.

If I file a bodhi update, it goes into updates-testing, and is available for testing and verification.

Once this update goes stable, it is in the final branched tree.

The rawhide tree (F-15, in this case) inherits its packages from F-14 if they're not built yet for F-15. Right now, it only inherits packages in the stable branched tree.

It has been proposed that rawhide be set to inherit from either updates-testing, or updates-candidate, so that more testing can be done of packages there.

= Problem space =

rawhide is not a superset of the previous branched tree.

= Solution Overview =

Flip the inheritance of the dist-f15 tag, and change how we initially set it in the future.

= Active Ingredients =

releng will do the switch.

= Owners =

releng is forwarding this on. The original idea came from Matthew Miller.
Who owns this proposal?


Me! I own the proposal!

Pros: more testing for packages, less languishing in the rarely-looked-at testing repo.
Cons: may be more risky for me to run Rawhide as my primary desktop machine both at home and work.

Replying to [comment:2 mattdm]:

Pros: more testing for packages, less languishing in the rarely-looked-at testing repo.

I don't really agree with this. First, rawhide and Branched have diverged. That's why they are different repos and scm branches. So Branched isn't going to get "more testing" this way. Rawhide might, but for things that are just being inherited I suspect that the rawhide testing isn't useful to the dev, only branched testing.

Secondly, everybody who installed Alpha, or any of the test/rc builds, have the testing repo enabled. Ditto anybody that installs from the nightly branched compose (the only compose we do that has images). I would NOT classify this as "rarely-looked-at". Maybe by you, but not in general.

Cons: may be more risky for me to run Rawhide as my primary desktop machine both at home and work.

More cons to follow.

I'll copy this to the ticket as well, but there are some non-trivial
roadblocks to this.

Koji "latest package" and inheritance works thusly, assuming looking for
the latest 'systemd' in dist-rawhide:

Koji will check the dist-rawhide collection and see if there is a
systemd specifically tagged with dist-rawhide. If so, return the last
one tagged. If not:

Koji will check the first level of inheritance to see if there is a
systemd specifically tagged with the first level of inheritance. If so,
return the last one tagged. If not:

Koji will check the first level of inheritance of the first level of
inheritance of dist-rawhide to see if there is a systemd ....

How this practically works right now is that when you ask for the latest
systemd in rawhide, koji looks at:

dist-rawhide -> dist-f15 -> dist-f14-updates

Right now we find something at dist-f14-updates and stop there. Further
searching would look in dist-f14, dist-f13-updates, dist-f13 and so on.

If we are to change this, we'd have to replace dist-f14-updates as the
first level of inheritance from dist-f15 to either
dist-f14-updates-testing or dist-f14-updates-candidate. This poses a
problem though.

In the case of dist-f14-updates-testing, while the first level of
inheritance there is dist-f14-updates, there are many times when
something goes into -testing, then something newer goes into -testing
without obsoleting the older build, then the newer build goes to
-updates. In this scenario there is an older build specifically tagged
in dist-f14-updates-testing and that would be picked up in dist-rawhide,
potentially going /backwards/ in n-v-r. To fix this the bodhi
obsoletion code needs to get a lot better, or a "3rd party" script needs
to be continuously ran to ensure that there are no older builds sitting
in dist-f14-updates-testing.

In the case of dist-f14-updates-candidate there are many builds that
land here, and only some of them migrate over to
dist-f14-updates-testing or dist-f14-updates. There is /no/ code right
now to untag things from -candidate when something newer comes along, so
the inheritance check would stop at -candidate just about every single
time, and often pick up builds that are older than what's in -testing or
-updates. A potential way to fix this is to have bodhi not /move/ the
build from dist-f14-updates-candidate into -testing or -updates, but
instead just add -testing or -updates as a secondary tag to the build.
This should ensure that the latest /built/ is nearly always the latest
/tagged/ in -candidate. What side effects this might have on the rest
of the system I don't know at this point, but messing with our tag
structure is not something to be taken lightly.

Another approach to solving the problem that rawhide has older builds than Branched testing repo is to force everybody to always do a corresponding rawhide build. Right now some builds are only done for Branched and people rely on koji inheritance to get those builds into rawhide; if there was a policy in place which prevented doing a Branched build with higher EVR than in rawhide, then the original problem should also go away.

Not sure if it's something desirable though as it would create additional maintainer burden. Also, with such a policy in place a failing rawhide build might make it significantly harder to get a build done for Branched.

Isn't it one of the AutoQA goals to enforce that builds in Fn are always versioned the same or higher than in F(n-1)?

With dist-git doing the rawhide build isn't significantly harder, one can commit the changes to master, kick off a build, then merge the changes back to f14 and do the build/update there too.

You are right and that the build might fail on rawhide. It'd be nice to have rawhide tenders, proven packagers who will help out when something like that happens so that the maintainer can keep concentrating on the pending branched release.

We agreed at todays fesco meeting (2010-08-31) to send out an email to devel announce asking all maintainers to please remember to build in rawhide before they build for f14.

Changing the inheritence is not something we want to do at this time. (See jkeatings notes above for problems changing it over to updates-testing would cause).

If we can just get maintainers building for rawhide too this issue will go away.

Login to comment on this ticket.

Metadata