On Tue, Mar 22, 2005 at 01:01:24PM +0100, Wouter Verhelst wrote: > On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote: > > This adds up to a lot of effort for a dead-end architecture. Do you believe > > that such ports are going to command enough interest to be able to keep up > > with Debian's stable support requirements for more than 2 1/2 years (18mo. > > release cycle + 1 year support for oldstable) after being discontinued as a > > product? > I'm assuming you're talking about m68k here. If not, please correct me. Hmm, not particularly. I don't really have any preconception/prejudice that the processors need to be in ongoing use in new *desktop* products; Debian obviously runs the gamut from mainframe to server/desktop to embedded. If the m68k architecture is still being used in new systems capable of running Debian, then I think this requirement is met. > m68k has been EOLed in desktop hosts for about 10 years now. There are > still people interested in it, who install Linux on their old hardware > for the first time, even today. > I think that pretty much translates to an answer of 'yes' to the above > question. Possibly, but I'm not convinced that potential userbase size ever guarantees a viable port just by numbers alone. I don't know if the liveliness of the m68k community is related to the continued availability of new m68k processors (which are still available, based on the general response I've gotten that this requirement doesn't affect any of our current ports? Even though I don't know where to find a new m68k myself). I would be inclined to suspect that it is. > > Furthermore, do you believe that the limited resources of DSA (which will > > *always* be limited, no matter how big you say you want the team to be, > > because there's *always* more to do than there are people to do it) should > > be spent keeping stable security buildds for such architectures running, > > instead of on tasks that are useful to users of living architectures? > There is some overlap between the groups of 'DSA' and 'buildd admins', > but a) that overlap is not absolute, and b) that overlap is not > necessary. > If the DSA people do not have enough time to spend in keeping stable > security buildds for old architectures running, they are welcome to hand > over buildd maintenance to other people; there are enough experienced > people to take over, if required. If they choose to do so, that's fine with me; however, particularly for buildds for stable-security, I think it's important that the machines be under the de facto authority of DSA -- even though they might delegate a particular machine's administration to someone who doesn't have authority over Debian machines in general. > > > If the point is to set an upper limit on the length of time a single > > > package may take to build, why not take that directly as a criterion? > > > It is even more objective. It might also encourage people to split > > > unreasonably large packages. > > Wouldn't this also be an arbitrary penalty on slower architectures, though? > Yes. > In the specific case of OpenOffice.org, the point is moot. > OpenOffice.org requires some assembly glue, so needs to be ported to > every architecture it runs on; currently, there are OpenOffice.org > packages for i386, powerpc, sparc, and s390; none for any of the slower > architectures, and doing them wouldn't be possible without someone > spending their time on it anyway. The OOo example was not mine; much better examples, I think, would be some of the math processing packages (quantlib, axiom -- fairly unlikely to require security updates, after all), X, KDE, or the mozillae. > > The porters don't control the size of the largest packages in the archive; > > and package sizes do continue to go up, just like everything else. > Not just that; package build times for equally-sized packages continue > to go up as well, because of increased optimisation. Indeed. So eventually, all architectures will be able to run the code, but none will be able to build it. ;) > > Build time for a single package is also only one of the concerns; the other > > big one being that it's much more likely to get security wrong for one out > > of ten buildds, rather than for one out of three. > Are there any specific concerns, or is this just a general feeling that > we m68k people might not know what we're doing, security-wise? It is a general comment on mitigation of security risks. > If the latter, spelling out a security policy that we have to follow > might be another alternative. I think that's also a good idea. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature