Re: A hack to alleviate transitions in Britney; now what?
* 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
Reply to: