> 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. > > > > 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. > 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. > 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. > Seems to make sense yes. > > > 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 current Architecture: list should do ? > 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. > > > * 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)? > AFAIK not, but you never know. > > > * 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. > 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. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature