On Thu, Apr 14, 2005 at 08:24:52AM -0500, John Goerzen wrote: > On Wed, Apr 13, 2005 at 09:22:24PM -0700, Steve Langasek wrote: > > On Wed, Apr 13, 2005 at 06:44:33PM -0600, Ean Schuessler wrote: > > > I didn't post that status nor are we actively monitoring it. Someone from > > > Alpha needs to get proactive and run the ball if they care about that > > > machine. > > The problem there, however, is that there aren't actually any Alpha porters > > today. Alpha is port*ed*, past tense, with very little ongoing work; the > > people listed at www.debian.org/intro/organization are not currently > > involved (at least one of them is no longer active in the project), and > > those of us who take care of the alpha-specific code bits on an ongoing > > basis, like the installer, kernel, and bootloader, have no formal status as > > porters. We also have no authority over build daemons. > Well, I don't think it's quite that dire. The previous primary buildd for alpha has been off-line now for about 9 months. The porter machine for alpha has been off-line now for 2-3 months, IIRC. That leaves the project with one operational alpha total right now. The ARM architecture has two buildds currently on-line; the normal complement required to keep up with unstable seems to be four. Efforts are being made to get a third buildd up, but until a few weeks ago we were down to *one* buildd, so it's no surprise that progress is slow. At least we have a porter machine up, but for a long time we didn't have that either. Mips and mipsel have each taken turns over the past year suffering from a lack of horsepower. They are both in pretty good shape right now. Sparc only has one machine on-line right now, vore; although many developers do have logins on vore, as usual with buildds, using it for porting work is discouraged. The secondary buildd, auric, is down and most likely is not coming back: the local admin for the two machines wants to down vore and replace both machines with a single chassis. I don't know if I would say "dire", but things look pretty messed up to me. > But it's misleading to assume that there are no other people that help > out with Alpha matters. As an example, I'm not terribly active on the > Alpha list, but I do have an Alpha, and have recently worked on obscure > exim4 bugs, helped out a bit with the GHC port, and found a working > ctx+util-vserver combination for Alpha and shared these observations > with the Debian maintainer. Indeed, there are people that help out with alpha-specific bugs, but this doesn't translate to taking responsibility for Debian's machine needs. > > So it's all well and good to say that "someone from Alpha" needs to get > > proactive, but AFAICT, that's an organizational null pointer; and I think > > this is in fact part of why our ports have been so hard to corral for sarge, > > because "porters" only exist for new ports, and we have no other process for > > people to assume responsibility for the overall health of a port. > I think there are people, but they are less centralized than you would > prefer. There are always arch-specific bits, such as bootloaders. But > past that, there's little more to maintaining an active port other than: > 1) Finding problems, reporting bugs, submitting patches > 2) Answering questions on the mailing lists from developers that need > help solving an arch-specific bug > 3) Making sure we have a working buildd and debian developer machine > And 3 is as much a DSA problem as anything. Yah, the problem with that is that it's not really reasonable to expect DSA to be passionate about each and every one of the 11 ports, the same way porters with a direct interest would be. Just as we shouldn't expect brainfood to be passionate about every piece of hardware they've agreed to host for us. Unfortunately, these seem to be the people that have been left holding the bag. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature