On Mon, Aug 29, 2011 at 08:58:34AM +0200, Lucas Nussbaum wrote:
> TL;DR: I think that we should have a discussion about the respective
> roles & responsibilities of maintainers and porters with regard to
> porting.
I've re-read this discussion a couple of times, with the intention of
summarizing it and propose how to proceed. The discussion has been
interesting, and it even seems to me that several of the positions
expressed are in fact in agreement with each other, despite the various
rebuttals on marginal points. My problem is that the *concrete* goal of
this discussion is obscure to me.
Let me recap. The problem raised by Lucas is clearly concrete. There are
hard porting bugs out there and they might hit packages with a lot of
reverse dependencies ("key packages") such as Ruby. Due to incomplete
knowledge, often neither porters nor maintainers working alone will be
able to fix them. That's why collaboration among the two is what we
recommend. But it also happens that some of those bugs are too hard to
fix, maybe temporarily due to manpower shortage, maybe for a long time.
We can clarify responsibilities and push them nearer maintainers or
nearer to porters, but I don't think that would change anything. It's
not like an overworked (or MIA) porter (or maintainer) will be more
likely (or more able) to fix a bug, just because suddenly it's more of
their responsibility to do so than it was before. So, *if* the point of
the discussion is assigning responsibility --- point that seems to be
the most controversial of the thread --- I don't think I see the point.
Still, this kind of discussion is recurrent. We clearly need to do
something about it. Here are a couple of proposals:
- We have an unhealthy asymmetry: a package $pkg who has never been
built (or has never worked without anybody noticing) on $arch don't
get in the way of a maintainer, while if $pkg suddenly stops working
on $arch it will get in the way of the maintainer as it blocks testing
migration.
I think maintainers should be empowered more to fiddle with the
Architecture list of their packages, but also that they should give
some sort of explanation (as simple as bug report pointers) for the
architectures they do not support. In the Ruby example, if the
maintainer has tried to fix the porting issue, asked the porters for
help, and still failed, then he should be allowed to file a "RM: ruby"
request (Pabs' point in this thread).
As observed by Phil, there will be a big fallout for a package like
Ruby. But *if* everything else have been tried by both maintainers and
porters, we don't have many other options. My point is: if the
maintainers were "allowed" not to support $arch for a NEW package in
Debian, they should be "allowed" to do the same for a subsequent
version. The point of the justification is to discourage maintainers
not to support $arch just because they are too lazy to do so.
Hopefully, not having $pkg on $arch would raise the visibility of the
issue and attract attention to fix the issue. In the meantime, the
fact that $pkg is not on $arch (and the justification for that) could
be used by the release team as a basis to decide whether $arch is in a
releasable state or not, exactly as it would be if $pkg were a NEW
package in the archive.
- Being able to judge whether the maintainers have done their part in
reaching out to porters is a requisite for the above. And to do so, we
really need more visibility of those exchanges. According to devref
[1], the contact points we currently recommend are both the
debian-$arch mailing lists and the $arch@buildd.debian.org addresses.
Is there any reason why the latter are not public? Or, conversely, is
there any reason why we cannot expect that people on $arch@buildd.d.o
are also on debian-$arch lists (maybe forcing specific mail
conventions to reduce mail load on people running the buildds)?
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#porting
> Release team, there's a question for you regarding ruby1.9.1 in the
> last paragraph.
Has this one been answered? (unless it was a rhetoric question :))
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature