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 $a...@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 »
signature.asc
Description: Digital signature