Anthony Towns <aj@azure.humbug.org.au> wrote: > So, I looked at the website, but all I can see are expensive PCs that > happen to have an arm chip. Put them behind a firewall on a trusted LAN, > use them to develop software for arm chips, and then just follow > unstable or run non-security-supported snapshots. Apart from writing > software for embedded arm things, I can't see the value -- and if an > arch is just going to be used for development, does it really need all > the support we give stable in order to make it useful for servers and > such? If so, why? If not, what level of support does it need, that goes > beyond "unstable + snapshotting facility", and why? Debian developers > manage to develop on unstable fairly well, eg, why isn't that enough? Is > this just a PR issue, in that "unstable" and "snapshot" aren't something > you can put on a brochure or brag about on slashdot?
This is very much a "What should Debian be" question, and I don't think trying to answer it along purely practical lines is reasonable. A moderately large number of our developers have become involved *because* we support these niche architectures - how do we reasonably quantify that and compare it to the effort required to keep them up to date? I do very much sympathise with the idea that expecting the release team to carry the burden of looking after under-maintained architectures is entirely unreasonable, but that doesn't mean that the only two choices are to drop architectures or to give up on releasing. We have more choices than that, we're just not sure how practical they are yet. I'm not going to agree with any "Oh, it's hard to release this many architectures" argument - I /will/ agree with "This architecture is holding us back, so we should drop it". Debian is a community project. Many people are involved because they want to be, not because they need to be. Implying that their work isn't massively useful isn't helpful, and may well have the effect of discouraging people who /aren't/ working on the potentially affected ports. If we're going to fail to release architectures, then let's base this on technical grounds rather than "I don't see any real reason why you need to release this architecture". -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
