Re: architecture-specific release criteria - requalification needed
* Ingo Juergensmann (ij@2005.bluespice.org) [050921 14:54]:
> On Tue, Sep 20, 2005 at 11:41:13PM +0200, Andreas Barth wrote:
> > | * Developer availability: The architecture must have a
> > | developer-available (i.e. debian.org) machine that contains the
> > | usual development chroots (at least stable, testing, unstable).
> > This criterion is there so that any developer can actually find out what the
> > issue is if his package fails to work on a specific architecture. Of
> > course, when adding a new architecture, there will be a time without a
> > stable release, and there will be some special arrangement how such a
> > machine can be provided without having even some packages in testing. But
> > that's not meant as a no-go, as long as we are quite optimistic that adding
> > the new machine will actually work in time.
> Well, for established ports, that shouldn't be a big deal, right?
I so wish this would be true ...
> > | * Installer: The architecture must have a working, tested installer.
> > Obviously, we need an installer. Though that doesn't say "debian
> > installer", we think that our users expect that there are not too many
> > different ways for them to install the released version of Debian etch one
> > day.
> Some obscure bootloader and a tarball of a mini-installation would be fine
> as well?
Well, probably not. As I said, we think that our users expect that there
are not too many different ways for them to install the released version
of Debian etch one day. So, there shouldn't be ten different and obscure
installers. But in the end, that will be of course a case-by-case
decision.
> > | * Porters and Upstream support: There is support by the porters and
> > | upstream. This is especially true for the toolchain and the
> > | kernel.
> > Obviously, we cannot keep a port alive if there is nobody doing support for
> > it. Of course, it is quite possible that Debian and upstream support is
> > done by the same persons. And our experiences with support of gcc-4.0
> > on m68k have shown that it is possible to get such issues fixed, if the
> > porters are notified in time and are really interested in their port (and
> > if there are enough porters).
>
> Uh, well, I hope that slower archs will be given a large time frame to fix
> things than faster archs? It would be unfair to give just a week time to fix
> a problem, when the recompilation of the package would take 10 days,
> wouldn't it? ;)
I think the current way with m68k really works for all involved parties
(at least it does from my point of view :).
> > | * Archive coverage: The architecture needs to have successfully
> > | compiled the current version of the overwhelming part of the
> > | archive, excluding architecture-specific packages.
> > Our back-of-the-envelope number for this criterion is 98%. As pointed
> > out multiple times during recent discussions, we don't have a good way
> > to measure an architecture's compliance with this yet, but we'll work on
> > figuring that out; of course we will exclude hardware-specific packages and
> > buggy optional/extra packages with severe portability issues, but
> > porters must take responsibility for working with maintainers to fix
> > portability issues.
>
> I still believe this definition is far too strict (without being precise).
> You can't say, you have to be 98% uptodate without saying what you
> understand by "being uptodate". As already outlined during the last
> discussion: when all m68k buildds are building package, that can easily be
> more than 110 packages marked as building and therefore missing as installed
> (given a total of 5500 packages).
> Currently m68k has ~650 packages listed that are not in state Installed (203
> Needs-Build, 142 Building, 180 Failed, 123 Dep-Wait (+ 5 Failed-Removed + 25
> Not-For-Us)). That's roughly 6% of all packages.
> And when does that percent mark need to be reached? After freeze or at any
> time before a release?
Basically any time. However, we might need to readjust the number. If it
makes you feel better, please read the number above as "a very high
number".
> > When reviewing the past however, m68k as the architecture with the most
> > autobuilders isn't performing too bad regarding the availability of the
> > autobuilders. So, there is the chance for m68k to get grandfathered in
> > for this clause. However, we expect that they explain why the higher
> > numbers of buildds they use are not as bad increasing the maintenance
> > overhead.
>
> I think (and believe that many DDs will agree) that m68k, although being one
> of the slowest archs, is one of the most responsive ports within Debian and
> that having that many buildds is nothing negative at all.
As I said: We think the m68k port is doing well, and for this reason, we
consider to grandfather it in. But that won't happen without a mail from
one of the porters asking us to do it, and providing some facts why this
is a good idea. :)
> > | keeps their autobuilders running for 24x7,
> > Of course, autobuilders can have hardware maintainence. But the
> > autobuilders need to be able to run 24x7, and the need to be generally
> > up all the time (and thanks to the redundancy above, there should always
> > be an autobuilder currently running).
>
> The more buildds, the higher the chances that at least one buildd is up and
> running. 24/7 is just normal for a buildd.
Of course. I think that failure of this criteria just shows that this
architecture is not ready.
> Sometimes it seems problematic to find a porting machine, though, because
> db.debian.org/machines.cgi is not always very uptodate.
And that is why we require to have a available porting machine (see
above).
> > | has autobuilders acceptable for security support.
> > If we want to do security support, that of course needs to be there.
> Again, is it required that those security buildds are different machines
> from normal buildds or how should that be handled? And for what dists is
> this required? For stable security, testing-security, etch-secure?
For the suites supported by security.debian.org. And about the
requirements: Basically that the security teams trusts the buildd and
the admins there enough to allow embargoed bug fixes to get onto this
machine. (Of course, this is only my impression what the security team
wants - it is their decision in the end if a buildd is acceptable for
security support or not.)
> > So, of course the question is: Which of the current architectures do
> > fulfill this set of requirements? To get this answer, and because we
> > know there are currently architectures which do *not* meet the
> > requirements, all architectures will need to be requalified.
>
> How shall this requalification be handled? Who has to be contacted to make a
> requalification?
The release team.
> For m68k:
> [...]
don't go so fast :)
Well, it's of course the decision of the m68k porters team who of them
will do the mail. But I think some more bits than just "it's available"
would be good.
Cheers,
Andi
Reply to: