Re: Question for all candidates: inter-dependancy of works the growing Debian project.
Charles Plessy wrote:
> I started to wonder about modularity in the use of the Debian
> infrastructure in 2006, because of a problem with the clustalw package.
> As you can see on the graph, its popcon score started to decrease around
> july. (http://people.debian.org/~igloo/popcon-graphs/index.php?packages=clustalw)
> I found out that it correlated with a bug whose fix was kept in unstable
> because it was not built on some arches (clustalw is non-free). This was
> a frustrating experience: I had strong evidence that we were losing
> users and it took me many hours of efforts to get it built on the
> missing arches, on which I have never had heard of anybody using
> Clustal. The popcon scores restarted to increase shortly after a
> re-upload with version bump triggered the release.net autobuilders.
Since there's an opt-in auto-build service for non-free these days,
this should be resolved already.
> There is something interestign in this example: it shows the case of
> alternative services offered to a package maintainer (although one is
> not official). Both have similar functions, but their requisites are not
> the same (building non-free on official autobuilders is not allowed).
> When I talk about componentisation, I simply mean that the fate of a
> package could be the result of multiple bilateral agreements between
> teams. If there is build team A and build team B, then the package
> maintainer could collaborate with one or the other. It is not necessary
> competition: Debian will in the future release team S, release team B,
> release team V, like Stable, Backports, Volatile. For security support,
> the Security team has very high standards that do not necessary fit all
> packages (see the wordpress controversy for instance). Having either
> alternative security teams or schemes like "upgrade" or "best efforts"
> would allow to better fit upstream's strategy for instance.
There are only a few packages, which are affected by this and most
of these are handled on a case-by-case basis already, e.g. the way
Mozilla security updates are handled in Etch.
Security-wise, there's already ongoing (although currently stalled)
work to classify security support level deviations using debtags.
However, consistent quality across our (huge) archive is one of our
greatest strengths, so this needs to be handled with great care
and proper support in our package management toolchain.
Cheers,
Moritz
Reply to: