On Wed, 2011-11-23 at 01:49 +0100, Denis Arnaud wrote: > I guess that you are referring to the following procedure: > https://fedoraproject.org/wiki/Package_update_HOWTO#Requesting_special_dist_tags, aren't you? Pretty much, yep. > Is https://fedorahosted.org/rel-eng/ticket/4975 an example of such a > ticket? No; that's someone using the old buildroot override process. You used to have to file a ticket to request a buildroot override. > > > Indeed, I understand that procedure as being kind of equivalent, in > Rawhide, to the Buildroot Override procedure > (http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides) on branched > releases. Well...not entirely. The two achieve sort of similar goals, but they do have differences, and *both* exist for branched releases - it's not as simple as 'tags for Rawhide, BROs for branched'. A buildroot override is, kind of, the quick-and-dirty option: it just stuffs a build that hasn't yet gone through the update process fully into the main buildroot for a release. *All* builds for that release will then build against that version of the package (and not the one that's in stable) until the BRO expires. So it's slightly dirty, but usually it doesn't really cause problems. It's intended to be used to handle the classic case where you want to rebuild package A, then rebuild packages B, C and D that depend on A, then submit A, B, C and D together as updates. Without BROs you couldn't do this - you'd have to send A through first, wait for it to go all the way through the updates process, then build B, C and D after it was done. A tag is a heavier, somewhat cleaner option: it's effectively a rolling branch (I dunno if there's a more correct term for that) of the entire release in question. It doesn't do anything slightly messy to the official buildroot, like BROs do, but it does require rather more resources, AIUI; we couldn't provide a new tag for every little BRO-type situation, hence the BRO process. So tags are intended for bigger, more complex dependency rebuild cases, especially 'structural' ones - ones which come up over and over again. Boost fits that bill rather well. What you'd do is apply for a 'boost' tag, which would always exist from then onwards. When you had an ABI-incompatible boost change coming up you'd build boost *and tag it into that branch*, not the main Rawhide one (you can do this with fedpkg / koji). Then you could rebuild all dependent packages with the same tag at your leisure, and once that process was complete, tag the boost package and all the dependent rebuilds with the main rawhide tag simultaneously. Done correctly, this would mean there'd never be any dependency issue in the main rawhide repo itself. (Tags can also be used just for working on some especially experimental change you're not entirely sure you really want to land in Rawhide, at least not yet - it gives you a way to try something and then pull the plug if it turns out to go horribly wrong, without having to revert and rebuild all your changes). BROs don't exist in Rawhide simply because there's no updates process for Rawhide - as soon as you send a build tagged for the main Rawhide tree, it goes into the buildroot. So there'd be nothing for the BRO process to *do* in Rawhide. But tags do exist, because the use cases for them are still valid for Rawhide. > Could we imagine extending that Buildroot Override procedure be > extended, at least on Bodhi, to ask for Rawhide specific/sandbox tags? See above :) the creation of tags isn't automated and I believe isn't intended to be, for the reason that they're somewhat resource intensive, while BROs aren't. So it's safe to let people create an essentially unlimited number of BROs with no human in the loop, but for tags, you kind of want that manual stage. I'm sure releng will correct anything I got wrong there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
