On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
>
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in
> particular, the NMUer must not change the Maintainer field, and should
> monitor the bugs of the package).
So, this one is a fairly important topic. Let me try to summarize the
discussion thus far and to add some roadmap comments.
The crux is deciding what does it mean that the "bpo service has become
official". At the very least, it means that the resources (hardware and
peoplepower) needed to run it are now provided by Debian, rather than by
a 3rd party vendor. That is important for users as they don't need to
trust anything else than Debian. I believe this point to be fairly
uncontroversial.
The next question is whether the new bpo status entails new
responsibilities (e.g. doing the backport, caring for its bugs, etc.)
for "default" package Maintainers or not. It's clear from the discussion
that there are objections to the idea that it does. Quite
understandably, a good deal of those objections come from maintainers of
packages who get lots of bugs.
My first comment is that while we might decide that official bpo comes
with new responsibility, that's not a decision to be taken lightly:
current maintainers agreed to do maintenance without bpo on the table,
and forcing new work on top of people (who possibly disagree with it!)
is definitely not healthy.
Thinking about it, what we _conceptually_ need is pretty simple: a
mechanism to declare who is the Maintainer of the bpo package and
enforce its declaration. The responsibility of bpo maintenance will be
on the declared bpo maintainer. If the default maintainer wants to be
the bpo maintainer too, fine; if someone else wants to, fine too. One
way to do that would be to require setting new values for
Maintainer/Uploaders, possibly backing up the default values to
Orig-{Maintainer,Uploaders} [1]. Is there any reason *not* to do that?
We need to define such a mechanism before squeeze-backports gets open.
From what concerns the BTS, Don's proposal in [2] (the main one, not the
alternative solution) seems reasonable to me and others in the thread.
The proposal also seems to assume a different Maintainer field for the
bpo package, as hinted above, am I wrong Don?
The goal for BTS support is not bothering default maintainer when
default maintainer != bpo maintainer. To understand how to get there, I
fear we need an estimate on whether support for [2] can be ready in time
for squeeze-backports or not. If not, we can go for the alternative
solution proposed by Don and patching reportbug.
Once more, we need to choose among the two alternative paths ahead
before squeeze-backports gets open (and well before that, if we want to
patch reportbug on time).
Cheers.
[1] in fact, as there are similarities with what derivatives do, we
might want to do that in a generic way and push it to derivatives as
a standard way to give credit to the maintenance work done in Debian
[2] http://lists.debian.org/debian-devel/2010/09/msg00161.html
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella .......| ..: |.......... -- C. Adams
signature.asc
Description: Digital signature
