2011/11/22 Adam Williamson <awilliam@redhat.com>
[...]
Surprising, no, but it could certainly handled better.

You are absolutely right. I fully agree, but what's done is done: I made that mistake, Petr did not. I intended to perform a scratch-build, but omitted the "scratch" work... Sorry for that. I have learnt it "the hard way", and shall strive to do better next time.

 
The intent of the requirement for a week's notice *in advance* is so
dependent packages can get out ahead of checking if they'll work with
the new library without adjustment, and if adjustment is needed, get it
ready. So that when the bump lands, dependent packages can simply be
quickly rebuilt, and Rawhide only has major dependency issues for a day
or two, instead of two weeks while everyone runs around trying to adjust
for the surprise changes.

That makes full sense, of course. I have just specified that advance notice in the guidelines (https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master), so as to reflect this.

 
Really, for something with as many deps maintained by as many people as
Boost, it should be required for the bump to be done in a tag and all
(or at least most of) the rebuilds to be completed in the tag prior to
merging it back into the main Rawhide stream. Some groups already do
this, to the general benefit of all.

I guess that you are referring to the following procedure: https://fedoraproject.org/wiki/Package_update_HOWTO#Requesting_special_dist_tags, aren't you? Is https://fedorahosted.org/rel-eng/ticket/4975 an example of such a ticket?

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. Could we imagine extending that Buildroot Override procedure be extended, at least on Bodhi, to ask for Rawhide specific/sandbox tags?

Thanks

D