2011/11/22 Adam Williamson <awill...@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
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
