Re: How to define a release architecture
On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote:
> > 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.
>
> It's not because you can't buy a new machine, the arch suddenly stops
> being useful.
Let's not waste time debating stuff like this. Let us work on alternate
ways, or that rule might just remain, bad as it is. You know that, and so
do I.
> > > 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.
> >
>
> Marking them arch specific would be a good starting point IMO.
No. Maintainers use the arch specifications to trim down archs where the
package is meaningless or would not work. If a porter team deams an arch
should not have a package that is otherwise arch: all or arch: any, it
should not result in the maintainer getting bug reports or messing with the
arch spec in the package.
The not-for-us lists, plus a channel to get rid of any previous notions the
archive and testing scripts had for a package in a given arch would work
just fine, I think.
> > 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.
>
> You need something here yes, but by not as stringent as what has been
> proposed up to now.
Agreed. I gave some of-the-top-of-my-head sample thresholds. If you have
better ones, go right ahead...
> > 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 current Architecture: list should do ?
See above. IMHO we need something a little better.
> > 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.
>
> Except that this requires NDAs to be signed which people might not be
> willing to do.
Not for the testing security team.
Anyway, if people are not going to accept the security NDAs to keep a port
supported, and nobody who HAS signed the NDAs is willing to support the
port, that port has to go. There is no way around THIS one.
> > 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)?
>
> AFAIK not, but you never know.
So lets not turn this point into yet another contention point, unless there
is a damn good reason to. There is a good reason why it exists, after all.
> > > > 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.
>
> No. There needs to be some override procedure like we have for maintainers not
> doing their job. But that's beyond the scope of this discussion.
In this case, there is nothing to override, because the overrides are
actually changing something in the teams so that the team changes their mind
(that might actually mean there is nobody who opposed the change in the team
anymore, in a worst-case scenario).
So, this should not be a point of contention in this sphere at all. It
belongs in some other level. Let's drop this point as a contention point,
then?
--
"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: