Re: Bits (Nybbles?) from the Vancouver release team meeting
Steve Langasek a écrit :
The much larger consequence of this meeting, however, has been the
crafting of a prospective release plan for etch. The release team and
the ftpmasters are mutually agreed that it is not sustainable to
continue making coordinated releases for as many architectures as sarge
currently contains, let alone for as many new proposed architectures as
are waiting in the wings.
Would it be possible to have a list of such proposed architectures?
This change has superseded the previous SCC (second-class citizen
architecture) plan that had already been proposed to reduce the amount of
data Debian mirrors are required to carry; prior to the release of sarge,
the ftpmasters plan to bring scc.debian.org on-line and begin making
non-release-candidate architectures available from scc.debian.org for
unstable.
If scc.debian.org is not mirrored, it would be possible to have much
more place than now. Does it means that more architecture could be
supported? I am thinking of the SH port that would need to separate
tree, if I remember correctly.
> Note that this plan makes no changes to the set of supported release
> architectures for sarge, but will take effect for testing and unstable
> immediately after sarge's release with the result that testing will
> contain a greatly reduced set of architectures, according to the
> following objective criteria:
I would add:
- there should be at least 2N buildd admins for this architecture. A lot
of problems with buildds are caused by buildd admins unavailable at the
same time for a given arch.
Architectures that are no longer being considered for stable releases
are not going to be left out in the cold. The SCC infrastructure is
intended as a long-term option for these other architectures, and the
ftpmasters also intend to provide porter teams with the option of
releasing periodic (or not-so-periodic) per-architecture snapshots of
unstable.
My primary desktop machine is an i386, but it was sometimes ago and for
a limited period of time and hppa machine, because my i386 had problems.
It allowed me to continue my work on Debian packages. In the case this
new infrastructure is set up, does upload from a SCC architecture to
unstable would still be allowed? If no, source only upload must be
allowed again.
- there must be a sufficient user base to justify inclusion on all
mirrors, defined as 10% of downloads over a sampled set of mirrors
AFAIK, only i386 currently meet this criterion.
BTW, I am not sure this is really a good way to measure the use of an
architecture, mainly because users could use a local mirror if they have
a lot of machines of the same architecture. How about using popcon *in
addition* to that?
To be eligible for inclusion in the archive at all, even in the
(unstable-only) SCC archive, ftpmasters have specified the following
What about experimental?
architecture requirements:
I would add as for the core set architecture:
- there must be a developer-accessible debian.org machine for the
architecture.
This is important if you want the developers could fix bugs on their
package for SCC architecture. This is currently not the case of the
alpha port, and that sucks.
That let me raise a problem I see with such an infrastructure. Imagine
an FTBFS on an SCC architecture (let's say arch X needs an autotools
update). If it is not possible to have a high severity for this bug
(because it is "only" an SCC arch) , I am almost sure that it would be
ignored by a lot of developers. That would say that all SCC
architectures will be quickly unusable...
These objective requirements would be applied both to the other eight
architectures being released with sarge that are not currently regarded
as candidates for release with etch, and also to any porter requests
asking for new architectures to be added to the archive.
This plan has been signed off on by:
Steve Langasek (Release Manager)
Colin Watson (Release Manager)
Andreas Barth (Release Assistant)
Joey Hess (Release Assistant)
Frank Lichtenheld (Release Assistant)
James Troup (ftpmaster)
Ryan Murray (ftpmaster)
Anthony Towns (ftpmaster)
I think that supporting a lot of architectures is an important
difference between Debian and other distributions. Changing that could
have a dramatically influence of what users think of Debian. IMHO, such
an important decision should not be taken by a few developers. Maybe a
vote is need...
Bye,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian GNU/Linux developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: