On Tue, Jun 07, 2005 at 05:11:05PM +0200, Josselin Mouette wrote: > Le mardi 07 juin 2005 à 02:12 -0700, Steve Langasek a écrit : > > Oh, you'll also note that the traditional "slow" architectures (mips, > > mipsel, m68k, arm) aren't on this "problems" list. That's because a *lot* > > of effort has been put into providing sufficient parallelization for each > > architecture; the ongoing cost to *maintain* these parallel buildds is > > higher than to maintain a single buildd, and given that each of arm, mips, > > and mipsel have had instances over the past year where they were > > short-handed, I don't know how realistic it is to expect that they'll stay > > caught up through etch's lifetime. > > This isn't fair. Instead of throwing out these arches, why not let them > in the current state while there's some effort to maintain them, and if > these efforts actually slow down, then drop the architecture at that > moment? I think the effect of "your arch is now dead because it didn't keep up for the last little while" warning might be a little worse than "we don't consider your arch to be maintainable long-term to the same standard as the rest of Debian, let's work out to what level we can support it". > > The second most significant area of concern, for me, is having people being > > proactive about dealing with per-architecture build failures. There's no > > particular reason that should be the buildd admins' or the release team's > > area of responsibility, either; all it requires is people who know what > > they're doing to file sensible bug reports without gratuitously duplicating > > efforts, and people who know the architectures to help the maintainers sort > > out bugs. > > I agree. This is the maintainers' duty, not the release team's. And if > the problem is too complicated to solve for the maintainer, someone > willing to support the architecture has to help. If such a person cannot > be found, this is a sign the architecture cannot be supported in Debian. This is tricky to assign "blame" for, though. I've only had one (positive, as it turned out) experience with contacting a porter team for assistance with an arch-specific bug, but I can easily see situations where it's likely to be difficult to work out who is "at fault". - Matt
Attachment:
signature.asc
Description: Digital signature