2011/11/22 Adam Williamson <awilliam(a)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_di...,
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