Tue, 15 Mar 2005
Don't get me wrong, please.
Daniel Silverstone seems to think that, in my opinion, any reduction in the support of minority architectures is something I do not want to talk about.
That's not correct.
But this proposal, as it currently stands, will kill off m68k. If there are no stable releases with security support, I know for a fact that people won't be using it. I upgrade my unstable m68k box enough to know why.
I have no problem with us being sent to a corner of the Internet, one you have to look very careful for to find it. We are a minority architecture for a reason, and there's nothing wrong with that. I also have no problem with moving the strain of supporting the port onto the porters themselves, if there are problems for other people. However, the port should always remain a viable one; and only allowing us to do unstable doesn't do that.
Daniel also makes a few comparisons, ones that aren't actually fair.
Even though amd64 has proven that it is possible for an architecture port to survive outside Debian, I don't think it is possible for m68k to do the same. Amd64 is shiny, new, and hot; m68k is not. I don't think it is hard for the amd64 port to find new interested people should they have more work to do; but that doesn't mean that the same is true for m68k. In that light, I have no problem with us doing most of the work is that is necessary; but I do have a problem with us duplicating work that is already been done elsewhere. There's no point in that, and it might kill our port off, too.
It is also not quite fair to compare the m68k port team to Ubuntu. The latter consists of a staff of ~30 full-time paid employees; the former exists of a staff of (currently) ~7 people who manage this in their free time. Sure, if you've got ~30 full-time people, it's completely feasible to take an unstable snapshot and turn it into something nice and stable. The same probably isn't true for 7 hobbyists.
It's not that it doesn't make any sense to reduce the support for minority architectures–we knew that would one day happen–but when the day had come, we should have been part of the discussion. Even though it is officially a proposal, and not a given thing, it certainly didn't feel that way; and the feeling that the work I have been doing for the past four years would go down the drain at someone else's whim, well, made me very unhappy. With a proposal like this one that came totally out of the blue for the people involved, don't you think some of us are tempted to throw in the towel in disgust? Gee.
Evolution and large mails
Part of being a buildd admin is that one, at times, gets pretty large mails in plaintext. Such as this one:
20 r Mar 15 Quickstep Build (5,1M) Log for failed build of tetex-bin_3.0-1 (
Currently, I mostly read mail in evolution, and only do a few bits in mutt. One of the things I do in mutt is signing successful mails, because evolution isn't as easily scriptable as mutt is. Failed mails are usually replied to in evolution, though.
Not this one. When I hit the 'reply' button, it almost choked on the mail, and required a lot of processing time just to open the window. Really bad...
