Hi all, Following the successful attempt at establishing release qualification guidelines, next on the agenda is addressing the question of amd64, Debian BSD and so forth, by working out some archive qualification guidelines. We'll follow a similar sort of procedure to the release qualification stuff, starting with an open discussion on #debian-tech on OFTC on Friday (around 1200 UTC, 2005-12-30) and building up some pages on the wiki. For Linux architectures, the requirements will probably be a subset of the release qualification requirements; for non-Linux architectures (eg Hurd, BSD, OpenSolaris, Plan9, Windows, OS X, etc) there will probably need to be some additional kernel/OS specific requirements as well. The main limitations that stop us from accepting any architecture any developer cares to propose are that each additional architecture requires gigabytes of space on the main servers, which makes it harder to find suitable servers in the first place, harder to do backups and recovery, harder to administer those servers, and it means that automatic operations on the archive -- such as daily maintenance, lintian checks, and other sorts of QA -- take longer. Additionally, adding architectures focusses maintainer time on porting issues and fixing bugs specific to new architecutres -- which has drawbacks as well as benefits, as fixes specific to Hurd or BSD will often (re)introduce bugs on Linux systems, or simply take up time that could have been spent improving the software in general. That certainly doesn't mean that it's not worth supporting other architectures, but it does mean that architectures will need to demonstrate that the effort to support them isn't a complete waste of time. The main things for Linux architectures will probably be to show that there are real users of the machines that the architecture would cover, that a separate architecture is actually necessary, and that it will be reasonably supported; while non-Linux architectures will need to also show that Debian can support that OS (cf licensing issues with OpenSolaris, freeness issues with Plan 9, or social contract issues with debs for Windows or OS X) and that having a Debian version of that OS will actually be of use to people, when they could instead be using one of Debian's Linux architectures or a pre-existing distribution of that OS. Another issue for different OSes is how well it supports the "Linux" API, or the "modern unix" API -- having to make significant code changes to apps instead of just recompiling them, is a pretty large cost for the project, that needs to be balanced by similarly large benefits. On the other side of the ledger, there's also the possibility of demonstrating that while an arch might not be fit for a stable release, that it's worth putting some other support in place; eg, an extra suite so that Hurd or arm porters can do snapshot releases. The question there would be working out if the port in question is popular and supported enough to justify the extra disk, bandwidth and maintenance effort, or working out how to limit those costs (eg, by allowing snapshot releases to only last for a few months) so that less justification is needed. Anyway, that's the general idea; hopefully it'll become clearer later. Given release architectures have de-facto requalified, candidates for archive (re)qualification are ttbomk: * arm, m68k, s390, sparc * amd64, armeb * hurd-i386, hurd-powerpc * *bsd-i386 * opensolaris Some discussion of how to do the mirror split might also happen. :) Cheers, aj
Attachment:
signature.asc
Description: Digital signature