* Steve Langasek [Sun, 15 Mar 2009 19:55:50 -0700]: Hello, Steve.
> On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote: > > Now, this has its own set of problems and caveats as well, since if you > > don’t pay attention and take care of later cleanup, you end up with > > packages in testing that do not belong to any source in testing, which > > is bad. > Will there be reports produced on a regular basis of the stale libraries in > testing, and their reverse-dependencies, so that people can easily pitch in > to help with this later cleanup? There is a web page [1] that contains information about ongoing transitions, including those that are in need on cleanup (libdvdread at the moment). A list of packages is provided, and they are classified in two groups: “Pending migration” (that is, they’ve been successfully rebuilt in unstable), and “Not fixed in unstable”. The first group is the responsibility of the Release Team, and they’re most likely failing to migrate because of another transition (or, could be, because of RC bugs, but in that case removal at some point would be warranted). The second group (which is empty in the case of libdvdread) are the ones we can use help with. These will have RC bugs from day 0, and will be in the list of transition blockers (http://snipr.com/transition-blockers). Maybe once the transition is done, they should be moved to a separate list, I don’t know. Thoughts? Additionally, as I said in my original mail, the purpose of this is mainly to break ties between transitions once they are ready, and by definition a transition is not ready if still some packages are not rebuilt in unstable. Meaning, there will be really few packages allowed into this “second group”, if any, and removals from testing will be preferred in that case. Does this address your concerns? [1]: https://buildd.debian.org/transitions/summary.html (This page may move to release.debian.org eventually.) * Don Armstrong [Mon, 16 Mar 2009 00:48:22 -0700]: Hello, Don. > On Sun, 15 Mar 2009, Steve Langasek wrote: > > On Sun, Mar 15, 2009 at 04:44:08PM +0100, Adeodato Simó wrote: > > > Now, this has its own set of problems and caveats as well, since > > > if you don’t pay attention and take care of later cleanup, you end > > > up with packages in testing that do not belong to any source in > > > testing, which is bad. > > Will there be reports produced on a regular basis of the stale > > libraries in testing, and their reverse-dependencies, so that people > > can easily pitch in to help with this later cleanup? > Even better would be to turn this report into a set of bugs filed > against the set of reverse dependencies which are made RC at the time > that the transition migrates. As said above, failures to build against the new library are RC from day 0, and the intention is not to do transitions while those are open, other constraints permitting. As for packages that are rebuilt in unstable but not migrated, I don’t think RC bugs are approriate, since they’re not bugs in the package. We have the above mentioned list, which I think should be enough (since I don’t expect for those packages to remain without migrating for too long periods of time). > [I'm personally slightly concerned about relaxing britney allowing > testing to get into unreleasable states; a flag to re-enable the old > behavoir late in release would probably be good.] In addition to what Steve explained about the inevitable necessity to bend the rules for entangled transitions, let me clear up that this is not any flag in britney that enables the behavior permanently or globally. This applies to a transition on a case-by-case basis, with a conscious decision and need for manual action. Also, it is my expectation that the need for this will mostly disappear once we get this first batch of transitions done. Sounds good? Thanks for your feedback, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
