Re: Serializing transitions
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
Reply to: