In the past when branching new releases off rawhide, we have kept package inheritence in koji. This means that once an update was promoted into the branched base repo (or the branched updates repo once it exists close to release), they would be inherited into rawhide if there were no rawhide builds.
This allows maintainers to only do branched builds and not worry about rawhide builds.
However, this also means users using branched updates-testing get newer packages than rawhide, and rawhide lags behind on fixes until those updates are promoted into updates or the base branched repo. Sometimes this delay is quite long during freezes.
Additionally sometimes packages are inherited into rawhide that are not compatible with changes that have landed in rawhide over branched. (where the package needs rebuilding for a new ABI for example).
Given that it only takes a minute to fire off a rawhide build of a package before building the branched version, I'd like to propose we just drop the inheritence and ask maintainers to make rawhide and branched builds during those times.
In the event of maintainers not having time/resources to do so, I'd like to see if we can add some co-mainainers that do these builds for them. I'd be happy to step up and do so for some number of packages, and I am sure we can find more folks willing to help with builds.
I think this will result in more testing of things in rawhide that are going to branched releases soon, make sure rawhide always has the latest packages and only be a tiny bit more work for maintainers.
I'll mail the devel list for feedback as well...
+1
I saw that Lennart proposed dropping NoFrozenRawHide on devel list. I wouldn't be opposed to revisiting that but I think it's a separate discussion.
I agree with this proposal. The overhead with having to build in two branches is so low (at least until you keep both branches merged) that there is virtually no reason to allow the confusing inheritance in koji.
Inheritance is a constant cause of confusion and breakage.
Inheriting binaries just does not work. While I personally fail to see manually building in two branches as any kind of issue/overhead, perhaps the merge+build process could be further automated to provide a kind of source-level "inheritance" for the cases/times where a packager wants rawhide+branched to stay in sync.
+1 (Truth be told, I wasn't even aware of this implicit inheritance. I've always built Rawhide first).
+1 the inheritance was a surprise for many people.
+1, let's make the rawhide/f19 branches behave exactly like branches in any other project do.
I'd vote for this if there was enforcement in place to prevent anything being built in branches that is newer than rawhide. Without that, I fear rawhide would just be broken. People aren't going to merrily change their build habits, so something will need to be in place to force them to. That won't be popular.
+6
Kevin, I guess you can start working on it. We could speak about it on meeting if you wish, but we have long agenda anyway.
I mentioned this ticket to Dennis.
Adding him on CC.
He's intending to start the mass rebuild later today.
To satisfy both camps, could be Bodhi updated to tag the build into Rawhide once the update is submitted? This would satisfy "users using branched updates-testing get newer packages than rawhide, and rawhide lags behind on fixes until those updates are promoted into updates or the base branched repo." objection.
An interesting idea. It does mean adding more complexity to bodhi tho.
It would have to:
look and see if there was a rawhide build of the package, if so, do nothing. If there is, then tag it into rawhide too.
I guess if the branched update was unpushed we would leave it tagged in rawhide to prevent 'going back'.
I'm not sure how difficult or fragile the bodhi changes would be off hand.
The main objection I have to comment 13 is that it doesn't satisfy those who oppose inheritance.
Suppose the package doesn't build in Rawhide. With inheritance, the package maintainer will never find out. Tagging the build into Rawhide won't find the problem either. Only building the package in Rawhide reveals whether or not it's broken.
So inheritance pushes this problem to someone else -- eg. whoever happens to come across the package and tries to build it in Rawhide, or whoever is doing a mass rebuild. But it's the package maintainer who is the person who should fix this, because they know the package best and it's their job as maintainer.
dropping the inheritance was approved in ticket.
If anyone interested feel free to prepare new proposal.
Replying to [comment:14 kevin]:
Definitely, but it would be worth of IMO.
It would have to: look and see if there was a rawhide build of the package, if so, do nothing. If there is, then tag it into rawhide too. I guess if the branched update was unpushed we would leave it tagged in rawhide to prevent 'going back'.
Exactly, that was my idea.
Replying to [comment:15 rjones]:
Package may become FTBFS anytime and not only in Rawhide. So this argument is moot IMO.
Login to comment on this ticket.