On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote: > Debian has been known through the years for its excellent support for > many architectures. In theory, a released arch should be as stable as > the common/popular archs. (In practice, it is/was pretty close, which > is good enough.) > > This asset is not something to be proud of because of shallow > marketing reasons -- it benefits the whole Free World as many bugs are > uncovered, reported, and fixed, quite often by Debian people. It > would not be incorrect to say that, having in mind how many packages > are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports, > Debian is the most comprehensive testground of the GNU system. > > There is a disturbing and unpleasant tendency (which > probably has its roots in the Dark Times, i.e. the Vancouver Proposal) > to drop support for some problematic archs as years go by. That's > entirely understandable, but: > > - m68k was the first "kicked out" arch. AFAICT, it is essentially > dead now and not even a miracle can save it. I agree on the stance that it's essentially dead now, yeah. The latter part is not precisely true. If someone were to fix the technical issues with the port that exist today--which would qualify as a 'miracle'--there's a fairly good chance that the port might be resurrected; the m68k porters were always rather enthousiastic about their port. [...list of problematic architectures snipped...] > So, having in mind the obvious conclusions a sensible person could do, > namely > > * Support for old (and not only old) architectures cannot be infinite; > and there's a line to draw somewhere when it comes to a release. > * There should be an entitiy within the project to decide which arch > gets released and which not, which one is blocking the whole release > process and ought to be ignored for testing propagation, etc. > Naturally, such entity is the Release Team, and their criteria don't > seem bad. > * There's not much a DPL could do except some publicity and > RFH-oriented efforts which are known not to work well... Agreed on those points. > the apparent solution to the problem is: > > Porters are an extremely valuable resource, and the survival of an > architecture in the distribution is impossible without skilled > people who can fix the hardest problems, assist upstream > (especially toolchain packages) and Debian maintainers in fixing > the issues that prevent a specific arch to meet the release > criteria. > Therefore, it is essential to preserve, and even grow, such > resources by doing all possible to attract people with sufficient > knowledge and also pass that knowledge through. I agree. > (I hope that most of you remember how much insightful Thiemo's > analysis about mipsen problems were.) > > > If you managed to keep up reading until this point, my question to the > candidates is: > > What do you think the project should do (with or without or regardless > of your help as potential DPL) to preserve this goodness (maximum > supported architectures) for as long as possible? When package maintainers are informed of architecture-specific bugs in their package, they should listen to porters, and actively work on the bug, rather than expect that a porter will fix it (which happens rather often for architectures that are in a problematic state, because "it's not a release architecture anyway", thereby only enlarging that architecture's problems). Porters can't fix every architecture-specific bug; and reading unfamiliar code to hunt down why a bug fails on one particular architecture isn't always the easiest thing to do. Of course porters are available to help, since they're supposed to know the architecture, but that's a different matter. > Do you think it is "goodness" or you're in the "good riddance" camp? I'm clearly in the former camp. > Extra question to Wouter as a (former?) porter and buildd admin I'm still a porter; while the m68k port is mostly dead, there are still buildd hosts running that occasionally manage to successfully build something; and that is still uploaded. But these are far and few between. Also, I am an admin for one powerpc host. > (feel free not to reply at all; and for other candidates -- feel free > to reply if you want to): > > IMVHO the m68k team was one of the most energetic, enthusiastic and > tireless porter teams. It included many knowledgable people who > contributed upstream as well (Linux, GCC, glibc, binutils, etc.) Not entirely. There were people who contributed to the upstream kernel, yes. There were no people active in the Debian m68k port on the toolchain. That was one of the reasons of our decline; we had no in-house knowledge to fix our toolchain, and had to rely on outside contributors. I did manage to hunt down a few problems by myself, but it wasn't enough to turn the tide. > The release team made it clear that m68k can return as a release > arch at any time, so the kick-out for Etch was (supposed to be) > temporary. Why do you think the m68k port is not doing very well > (to put it mildly; [*])? Because we have no usable and modern toolchain ATM. If that were ever fixed, we could probably get in again at some point. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature