This one time, at band camp, Stephen Frost said: > * Stephen Gran (sgran@debian.org) wrote: > > This one time, at band camp, Stephen Frost said: > > > The clarification made it fairly clear to me that if this is > > achieved by the porter team running clusters with distcc and magic > > smoke, and has a back bedroom full of spare parts, that should > > satisfy the criteria. The point was that Debian's core > > infrastructure shouldn't be responsible for limping along a dead > > architecture that is essentially unavailable, and that security > > fixes and the like have to be done in a more timely manner. > > Ah, now here's a new one that I'm going to have to ask you to clarify: > What is "Debian's core infrastructure"? Is that wanna-build access? > Is that all the buildds? Only buildds for some archs, what archs, why > those archs? I think wanna-build access and the ability to upload > packages are important things an arch needs to be able to do. I think > having testing and stable is important too. I can understand *some* > criteria for getting access to these resources (5 DDs willing to sign > off on the arch, at least 2 buildds, whatever) but not those outlined > above... I interpreted 'core infrastructure' to mean something more like 'RM brainspace' or something. The actual technical side of it is something we have historically been good at solving, as others have pointed out. If we _are_ that good (and I think in general we are), and we're still having a hard time, a line has to be drawn somewhere, and that somewhere is apparently being drawn at the point of admin overload. It doesn't seem like an unreasonable line to me. If there is a basically doorstop architecture, say a Wang word processor, that someone wants to run Debian on, then feel free. Just don't expect the release team to coordinate security uploads, continuously massage buildd's and testing runs and so forth for you, was my interpretation. It seems like the people who came up with this proposal have been saying over and over that if the porter teams have their act together, they can release like everyone else, and they use amd64 of what they would like to see over and over. If the amd64 crew can pull it off, I think an established port should have an easier time maintaining itself. > > I see no reason why a team of interested individuals can't make this > > happen - magic smoke is cheap, after all :) > > It's still not entirely clear that distcc is the solution to the > problem here. Additionally, I'd rather have DSAs for things as they > become available than forcing us to wait till all archs are done to > make a DSA, in general. If that takes care of the N <= 2 requirement, > then great. I don't think that is very helpful to those who run production machines on sparc or alpha or $arch, though, and that is the point of this whole discussion. What architectures are going to do a good enough job that they can be supported in the manner that users deserve to be supported? I would love to see all the architectures currently supported, and a whole host of others that I have never heard of, get shipped with etch. It can happen, it will just take some work. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgpbGa3hKt_IH.pgp
Description: PGP signature