On Thu, Sep 22, 2005 at 01:52:06AM -0700, Steve Langasek wrote:
> On Wed, Sep 21, 2005 at 02:52:57PM +0200, Ingo Juergensmann wrote:
> > Although it was discussed several times, I have still no idea how those
> > users should be counted?
> > Who has to show those numbers? The users? The porters?
> "someone". That someone is probably a porter by definition, I'd say.
"Someone" is not necessarily a porter. That's why I asked. So, it should be
said that a porter has to do the reports.
> > So, a little more info is needed, how those numbers are counted.
> > Are users just meant to be ordinary users of does that included developers?
> Developers are users too.
Great if you see it that way, but it could've been different, though. :)
> > 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? ;)
> Why would it be in Debian's interest to be lenient with slower architectures
> here? The whole point of these architecture requirements is to prevent an
> individual architecture from dragging the release down, and "this
> architecture is too slow to debug effectively" is *definitely* an instance
> of dragging the release down. You're making a very good argument in *favor*
> of dropping such ports, I think.
Oh well, then again you could argue that every port that is slower than the
fastest port should be dropped, i.e. drop all archs. Is that what you want?
> > 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).
> Once again, what I'm hearing here is a plea for latitude towards certain
> ports because they're slow, instead of an acknowledgement that being slow
> (and therefore, failing to keep up) is what causes extra work for the
> release team.
No. Looking at s390, which ought to be no slow arch, there are currently 90
packages in Needs-Build, 116 in Building, 6 Failed, 39 Dep-Wait, 1
Failed-Removed and 28 Not-For-Us. So, a total of 251 (+29) packages marked
as not Installed. That's >2% as well.
That's why I asked how this number will be obtained.
> > 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.
> Yes, and a week ago the m68k porter lists were informed that the current
> state of m68k is unacceptable and that if significant progress wasn't made
> soon, we would ask for m68k to be ignored for all testing propagation.
Yes, and although there are at least two buildds that are not running
currently (because the local admin was very busy in the past) and even one
of them has a broken boot disk, the port is keeping up fairly well now.
> If an architecture fails the release candidate criteria for whatever
> reason, and is demoted to a non-release arch, I believe the sensible course
> of action is to give the porters a fixed two-month period to remedy the
> lapses before being re-evaluated by the release team. That leaves the
> porters free to focus on fixing whatever the issues are instead of scurrying
> to get re-qualified ASAP, and it also ensures the release team's time isn't
> wasted re-approving a port which qualifies at the instant but immediately
> becomes a liability again after being approved.
When a port isn't keeping up, it's already free to decide for the release
team to release that port or not. Instead, new, arbitrary numbers and rules
are raised.
And I still think this is a proposal? Shouldn't it be voted about before it
becomes reality?
> graphics/gem_1:0.90.0-17: Dep-Wait by buildd_m68k-kiivi [optional:out-of-date]
> Dependencies: libjack0.80.0-0 (>= 0.99.0)
> Previous state was Building until 2005 Aug 10 08:44:01
> This is a sampling of screwy dep-waits I was able to find by glancing
> through the buildd.debian.org webpages, and excludes those that I've already
> specifically asked the m68k porters to remove in the recent past because
> they were holding up transitions.
So, what is better: to set a dep-wait and maybe do something wrong or
setting no dep-wait at all and let the package in Building state for weeks?
> And sure, other buildd maintainers occasionally set a bogus dep-waits, but
> it seems to be m68k where I most frequently have to ask for their removal...
Which is usually corrected asap, right?
> > Ok, let's have a look at http://release.debian.org/etch_arch_qualify.html:
> > - 5 devs (porters): think so, yes: cts, adconrad, smarenka, smurf, rnhodek,
> > wouter, schmitz, younie
> I would prefer that we get this directly from the mouths of the developers,
> just to be sure; PGP signatures have been mentioned, though I don't think
> that was stated explicitly in the criteria list.
Why? The above mentioned people are the buildd admins for m68k. I guess that
should be good enough for that criteria.
(but in general, a gpg signatured mail is ok for that purpose, of course)
> > - buildd N<=2: no, not without crosscompiling, requesting exception
> > - buildd redundancy: best redundancy of all :)
> The N+1 redundancy rule is also based on the assumption that N <= 2. If N >
> 2 due to an exception, we probably have to consider the likelihood of
> multiple concurrent outages.
> Anyway, it's not clear that m68k currently has even N+1, because it was
> *not* keeping up with unstable for the past month or two and has only
> started to catch up now because new buildds have been brought on-line.
It was not keeping up, because there was a gcc issue to be fixed. And
there's still quickstep, which is currently building for etch-secure. You
could count that as +1. And I already asked if security buildds count as
normal buildds or are excluded from that count.
And it is not the slow archs fault alone that packages aren't built for that
long. Wanna-build itself is not very good in that regards. There were
already discussions about that in the past.
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: 2744150@sipgate.de
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
Attachment:
signature.asc
Description: Digital signature