Re: How to define a release architecture
On Mon, 21 Mar 2005, Peter 'p2' De Schrijver wrote:
> > * the release architecture must be publicly available to buy new
> >
> > Avoids a situation where Debian is keeping an architecture alive. This
> > isn't intended to result in an architecture being dropped part way
> > through a release cycle or once it becomes hard to obtain new hardware.
>
> What problem does this rule solve ?
IMHO, if one cannot buy one new, it is a mostly stale architecture that is
taking effort from the post-release teams (security, release manager,
DSA...). This is *not* an acceptable criteria for not-to-be-released(-yet)?
arches ("scc"), but it certainly makes a lot of sense for release ones.
If Debian is keeping an arch alive so much that one can still buy it new, I
certainly can't see why we should not continue releasing for that arch,
however. So I'd say Matthew's explanation is not perfect. But the
reasoning behind it is not difficult to spot.
Throwing out this requirement makes sense, if and only if there is another
way to get sure a released arch will not be left stranded. So, let's work
on these alternate ways, so that this rule can be removed.
> > * the release architecture must have N+1 buildds where N is the number
> > required to keep up with the volume of uploaded packages
> >
> > This is to ensure that all unstable packages are built in a timely
> > manner, and that there is adequate redundancy to prevent a single buildd
> > failure from delaying packages.
> >
> > * the value of N above must not be > 2
> >
> > This effectively sets an upper limit on the length of time a single
> > package may take to build, which helps ensure that doing things like
> > security fixes for Openoffice doesn't become a problem.
> >
>
> A far more acceptable alternative would be to not have openoffice on those
> archs.
IMHO you are quite right. If we can agree on that one, we should make it so
that packages that are effectively blocked from an arch count as an
arch-specific (of another arch) for that arch. I.e., they do not lower the
number-of-packages-built rating. So, they do not bother that arch at all.
Add a hard limit that at least the entire set of non-arch-specific standard,
required and essential packages have to be supported (or a minimum of 90% of
them, maybe?), plus at least 50% of optional and 50% of extra (again,
non-arch-specific) to avoid abuse, and that would do it.
DO note that we could also decide to accept that a buildd is something that
has the latencies of a [fast enough] single unit, so, e.g., a distcc farm
would count as one buildd. Makes a lot of sense to me, since it addresses
the latency problem... but you WOULD need N+1 *farms* in different
locations, etc. to address the reliability problem.
Let the porter teams release an *official* list of not-for-us packages for
their arch, which get permanently excluded from that arch's release, and
does not cause any sort of problems *at* *all* for the maintainer of said
packages (such as annoying problems with the testing scripts if the arch
drops the package after it had made it to testing for that arch), and I
don't see how that could be a bad thing.
> > packages are held back from testing by an architecture not being able to
> > build them.
>
> In which case those packages can simply be not available for the
> architecture in question.
Yes, IMHO. This would take care of it, as long as we have the proper
infrastructure in place to make it easy to manage.
> > * the Security Team must be willing to provide long-term support for
> > the architecture
> >
> > All releases require security updates, again for obvious reasons.
>
> This requirement can be satisfied by stating that some one must be
> willing to support the security team.
No. This requirement can be satisfied by having someone IN THE SECURITY
team willing to support the arch. There are various ways to make sure the
security team is willing to support one arch, and I believe the most
effective one is to get your hands dirty and go help them like crazy right
now, so that they trust they will have help for that arch should they need
it.
I'd suppose a damn good way to start is to make sure there are at least two
porters of every arch (and I *do* count i386, amd64, powerpc and other
popular arches here) *active* in the testing security team.
> > * the Debian System Administrators (DSA) must be willing to support
> > debian.org machine(s) of that architecture
> >
> > This is in order to ensure that developer-accessible machines exist.
>
> This requirement can be satisfied by stating that some one must be
> willing to support debian.org machine(s) of that architecture.
My guess is that it would need to be a machine under the DSA control to make
sure the security team and stable maintainership is never left out in the
cold.
Is this actually a problem for any current arch (either released or not)?
> > * the Release Team can veto the architecture's inclusion if they have
> > overwhelming concerns regarding the architecture's impact on the
> > release quality or the release cycle length
> >
> > A get out clause - it must be possible for something to be refused if it
> > would break the release, even if it meets all the other criteria.
>
> This is unacceptable. It would for example allow archs to be refused
> because their names starts with an 'A'.
Let's be very realistic here. If for some weird reason, any of the
post-release teams (security, DSA, release manager) will not touch any archs
whose name start with an 'A', how exactly can we keep these archs working as
a Debian stable arch must be?
We would have to do a parallel release or something like that, using
unofficial mirrors, etc... or to drop a released stable arch in the middle
of a stable release. This is *unacceptable*. Regardless of wether it is
acceptable or not that a post-release team refuses to work with a given
arch, as that problem does not have a solution in a volunteer-driven
project.
So, since "Get that team to work on that arch by force" is not possible,
this requirement is actually quite sane. And if you could get whatever team
is refusing to work with a given arch to actually work with that arch, then
you could have gotten them to stop objecting to that arch being released in
the first place.
Again, is that a problem for any current or prospective archs to be released
with etch?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: