Fwd: Archive architecture qualification

[Robert Millan]

Just in case you didn't see it ...

On Thu, Dec 29, 2005 at 03:32:43AM +1000, Anthony Towns wrote:
> 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

-- 
Robert Millan