Re: Maintainers, porters, and burden of porting
* Stefano Zacchiroli (zack@debian.org) [110908 19:22]:
> 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).
I disagree a bit here, tripple actually.
In any case, the package maintainer should ask the porters for help.
Just removing an architecture from the list of supported architectures
isn't a proper way to deal with it. Failing to get sufficient support,
removing then is still an option (and if urgent testing migration is
required speaking with the release team helps).
Also, if a package doesn't build, changing the architecture list has
no impact on the testing migration. The only relevant action is
removing the relevant binary packages. The architecture list could be
the same - it has no impact at all at the testing migration.
And last not least, if a package has many / relevant reverse
dependends, the package maintainer should speak with the release team
first because the package (e.g. ruby without sparc) won't make it to
testing anyways otherwise.
> 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.
I disagree with "let's first remove things". If a package like ruby
doesn't build on sparc this bug report is RC exactly as long as sparc
is a release arch. The release team has (and does) override such bug
reports for testing migration if appropriate. Removing the binary
package doesn't help at all but just makes things worse. So please
don't do it, especially for packages with reverse dependencies.
> - 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?
Yes. Because one of the most frequent users is the security team
asking where this and that security build is. We don't want that
public for obvious reasons.
> 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)?
Yes.
The difference is:
$arch@buildd is to reach the buildd admins.
debian-$arch is to reach the porters.
There might be overlaps, but it's definitly not the same. Porting and
maintaining a buildd are two different tasks, and the required skills
for porting are different than for maintaining a buildd. I know good
porters who are bad buildd admins, and good buildd admins who are bad
porters.
The current setup allows e.g. to shift buildds around as needed for
vacations, which would be way more ugly if I would have to subscribe
to all porter lists.
Andi
Reply to: