Re: A hack to alleviate transitions in Britney; now what?
* Adeodato Simó [Tue, 17 Mar 2009 18:25:10 +0100]: > * Raphael Geissert [Mon, 16 Mar 2009 18:32:51 -0600]: > > > Removing GNOME from testing because something depends on libfrufru1 isn't > > > a win for testing's usability. > > It would only last until it is able to migrate without breaking anything. I > > think this is just a matter of deciding which way is "less broken", i.e. > > broken because some packages are removed, or broken because you have > > multiple versions of the same libraries. IMHO the latter approach breaks > > testing more than the former, because it is a matter of availability vs > > duplicates (and if something goes wrong: installability). > If you can’t see how keeping another library around is more useful for > user than breaking half of their systems, I’d appreciate if you could > think if over again. I’m very sorry, Raphael, I didn’t want to be harsh: please accept my apologies. Removing packages is certainly an option when they are not fixed, or unmaintained, or candidates for removal from unstable. But removing maintained and fixed and useful packages to make a transition does not particularly help our users: new users of testing won’t be able to install the package, and old users will end up (in the best case) with the two SONAMEs of the library installed [in the worst case, they won’t be able to upgrade]. So, in keeping the old library around is what apt & co. is going to suggest to these users, I would say it’s appropriate to use it as a temporary solution to alleviate precisely that problem. Cheers, -- - 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
Re: A hack to alleviate transitions in Britney; now what?
* Raphael Geissert [Mon, 16 Mar 2009 18:32:51 -0600]: > > Removing GNOME from testing because something depends on libfrufru1 isn't > > a win for testing's usability. > It would only last until it is able to migrate without breaking anything. I > think this is just a matter of deciding which way is "less broken", i.e. > broken because some packages are removed, or broken because you have > multiple versions of the same libraries. IMHO the latter approach breaks > testing more than the former, because it is a matter of availability vs > duplicates (and if something goes wrong: installability). If you can’t see how keeping another library around is more useful for user than breaking half of their systems, I’d appreciate if you could think if over again. Cheers, -- - 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
Re: A hack to alleviate transitions in Britney; now what?
* Richard Atterer [Mon, 16 Mar 2009 13:34:17 +0100]: > At the very least, there should be an auto-generated web page listing > packages in testing that are currently unreleasable! http://lists.debian.org/debian-devel/2009/03/msg00836.html -- - 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
Re: A hack to alleviate transitions in Britney; now what?
Steve Langasek wrote: > On Mon, Mar 16, 2009 at 12:17:28PM -0600, Raphael Geissert wrote: >> Wouldn't it be better to remove the packages from testing? this way if >> the library and other packages are ready to go they could easily migrate >> without any special hack, if my understanding of the situation is >> correct. > > In some cases, if you want a completely consistent testing you have to > remove dozens of source packages for the benefit of one "extra" binary > package that's built from the same source as something important. > > Removing GNOME from testing because something depends on libfrufru1 isn't > a win for testing's usability. > It would only last until it is able to migrate without breaking anything. I think this is just a matter of deciding which way is "less broken", i.e. broken because some packages are removed, or broken because you have multiple versions of the same libraries. IMHO the latter approach breaks testing more than the former, because it is a matter of availability vs duplicates (and if something goes wrong: installability). Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
On Mon, 16 Mar 2009, Adeodato Simó wrote: > 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. Cool. > 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. Right; I really only meant the cases in which someone has to do something to clean up the transition. (For things that only the RMs can do, it doesn't really make a difference to me how it's tracked, though bugs in the BTS against an appropriate psuedopckage using the 'affects'[1] mechanism to indicate which packages have a problem would help other people besides the RMs know what was going on.) > 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. That's good enough for me. I didn't understand that it involved manual action. Don Armstrong 1: This isn't working 100% yet; I hope to have an announcement about it and summary shortly. -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. -- Richard Feynman "What is and What Should be the Role of Scientific Culture in Modern Society"; 1964 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
On Mon, Mar 16, 2009 at 12:17:28PM -0600, Raphael Geissert wrote: > Steve Langasek wrote: > > On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote: > >> [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 practice, the release team has to do this at various points in the > > release cycle anyway because the transitions become so entangled that > > breaking something in testing, or removing a bunch of packages that we > > intend to release with, are the only options. This approach at least > > ensures that testing will remain installable and (presumably) useful > > during the rocky transitions, merely requiring a bit of cleanup of old > > packages. > Wouldn't it be better to remove the packages from testing? this way if the > library and other packages are ready to go they could easily migrate > without any special hack, if my understanding of the situation is correct. In some cases, if you want a completely consistent testing you have to remove dozens of source packages for the benefit of one "extra" binary package that's built from the same source as something important. Removing GNOME from testing because something depends on libfrufru1 isn't a win for testing's usability. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
Steve Langasek wrote: > On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote: > >> [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 practice, the release team has to do this at various points in the > release cycle anyway because the transitions become so entangled that > breaking something in testing, or removing a bunch of packages that we > intend to release with, are the only options. This approach at least > ensures that testing will remain installable and (presumably) useful > during the rocky transitions, merely requiring a bit of cleanup of old > packages. > Wouldn't it be better to remove the packages from testing? this way if the library and other packages are ready to go they could easily migrate without any special hack, if my understanding of the situation is correct. This change would not affect users of the removed packages, because unless the new library conflicts the old one, no package would break on installed systems. This schema is more or less what Richard Atterer is proposing, but instead of solving the transition on the archive, it would be happening on the user's machines. What do you think? Whatever happens, thanks for your work! :) Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote: > [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.] Adeodato's proposal makes a lot of sense, but still I agree with the above. "Always in a releasable state" was a good design decision for testing, and this change will muddy the idea a bit further. At the very least, there should be an auto-generated web page listing packages in testing that are currently unreleasable! For a cleaner separation, testing could be split it two: The normal, releasable testing works according to the strict rules as before. A second, add-on repository (let's call it "mouldy";-) can realize Adeodato's idea: It is only intended to be added to sources.list _in addition to testing_, and contains out-of-date library packages and the programs which depend on them. Rather than removing packages from testing to make way for a new transition, britney would move them over to "mouldy". This way, they would still be available. At the same time, the fact that they moved there is a clear sign to the respective maintainers that they need to do something to get their packages into a releasable state. Once the problem is resolved, those packages which only indirectly depended on the library transition can be moved back from "mouldy" to testing without recompilation. I can't say I'm too much of an expert with these issues, so there may be problems with this scheme. For example, it is possible that "mouldy" would end up containing everything and testing would be empty, which would buy you nothing. :) Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
On Mon, Mar 16, 2009 at 12:48:22AM -0700, Don Armstrong wrote: > [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 practice, the release team has to do this at various points in the release cycle anyway because the transitions become so entangled that breaking something in testing, or removing a bunch of packages that we intend to release with, are the only options. This approach at least ensures that testing will remain installable and (presumably) useful during the rocky transitions, merely requiring a bit of cleanup of old packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
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. [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.] Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, "Chew more! Do more!" The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A hack to alleviate transitions in Britney; now what?
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? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
