On Fri, Mar 26, 2010 at 03:11:12PM +0100, Raphael Hertzog wrote: > On Fri, 26 Mar 2010, Marc 'HE' Brockschmidt wrote: > > You mean like the existing pages on buildd.debian.org? You just need to > > feed them the list of affected packages to get that. > > Good if it can be done with a simple link to buildd.debian.org! It would > still be nice to be able to attach some information like bug numbers near > FTBFS so that people managing the transitions know whether all failures > have been reported.
If the buildd maintainer adds the bug number when he sets the package to failed state, you can see that and it will provide a link to the bug. But not all buildd maintainers have the time to follow up on all the failed build mails they get, see if there is an open bug or file a bug report, ... Anyway, if you think something could be improved to the website, feel free to sent suggestions or patches. > > > Multiple transitions will still end up mixed in sid if you push them > > > before packages have migrated to testing but they are all already > > > completed and you only have to deal with RC bugs and delays to ensure > > > package can migrate to testing. > > > > "Only" deal with RC bugs? This touches an interesting point you didn't > > cover at all: How are bugs reported? How can these bugs be tracked if > > the same source version is fine in sid, but breaks in an overlay - or, > > worse, breaks in one overlay, but not in another? > > Bugs are reported like usual. However you are right that we need to extend > our bin-nmus versioning scheme to avoid collisions in package versions > between various overlays. And/or we need to extend our tools to be able to > explicitly give the source version The BTS supports filing bugs against source packages, so you also file against the version of the source package. A FTBFS bug is now almost always reported against the source package, including binNMUs. The problem is that version information often is not good enough to say which versions are all affected. A change in some packages might result in some bug against an other package, this often happens in case of transitions. It often happens that a package in stable and unstable have the same version, but the problem doesn't happen in stable. Which is why we also have tags like lenny squeeze and sid to say to which suites the bug applies. > It might also mean some changes to the version-tracking code. I guess we could extend the version track to use such tags too for overlays. > > > Dealing with transitions that way make it clear that the maintainer has to > > > take the responsibility to prepare/complete the transition if he wants to > > > see his package in sid and in the next release. I think one problem with this it will make transitions with many packages involved even harder that it is today, while I think that's not something we want to do. The problem is that some packages are not maintained anymore, don't work anymore with the new version, or whatever. The release team would then just remove (or break) some packages in testing, while you seems to want to make it impossible to even get in unstable. > > > Preparing the transition in experimental is not always done and takes > > > much more energy than such a system would take. > > > > Why, actually? > > I don't an exhaustive answer but here are some points: > 1/ you can't request bin-nmus of reverse-dependencies in experimental > (to verify that all packages build fine with the updated package, and > that's one of the main task in preparing the transition) There are basicly 3 types of packages in transitions: - Those that keep working with the new version - Those that break building - Thsoe that break running But the problem is detecting which package falls in which category. Failing to build clearly is the easiest to detect. It's not that hard to rebuild all the packages against 1 or more packages from experimental. But you probably want to do that on as many arches as possible which is why you want to request binNMUs. The problem however is that we currently don't have enough information to know which packages from experimental and which from unstable you want to take, and the buildd infrastructure does now allow you to schedule a binNMU in some suite if there is no source package in that suite. I assume dak would also reject the package if it can't find the source in that suite. If you want to go that way, those will atleast need to get changed. So I think there is a need to do rebuild tests across several arches, atleast for some transitions. And it would clearly be useful that those binaries could be used to do runtime tests. If it does break building, you obviouly want to upload a fixed package to experimental. Anyway, I was thinking if it would be useful to have different experimentals and that you would need to upload it some new "transition" in experimental, like "experimental/libfoo5", so that people that want to use that can use that, instead of forcing it on everybody. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327221320.ga15...@roeckx.be
