|
|
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.
|
|
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
|
