Fwd: Archive architecture qualification

[Aurelien Jarno]

On Wed, Dec 28, 2005 at 07:17:24PM +0100, Robert Millan wrote:
> 
> Just in case you didn't see it ...

I have seen it, but I won't be able to be there (at least partly),
because I will be in the train...

We should have at least one of us following (and participating in) the
discussion. Who would be there?

Bye,
Aurelien

> 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
> 
> _______________________________________________
> Glibc-bsd-devel mailing list
> Glibc-bsd-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/glibc-bsd-devel
> 

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32 at debian.org         | aurelien at aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net