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. > Is it intended that a user should mail debian-release to say "Hi! I'm using > port X!"? I doubt so. No, please assemble a list of users willing to vouch for their use of the port and submit it to the release team when it's complete. > 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. > > | * 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? ;) 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. > > | * 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). 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. > 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. Your percentage is a bit off, btw; 650 is 7% of all source packages in unstable, and if you *exclude* packages that are in P-a-s, the percentage would be higher. This is reflected on <http://buildd.debian.org/stats/graph2-week-big.png>. > And when does that percent mark need to be reached? After freeze or at any > time before a release? The intent was that the threshold should be met on an ongoing basis. Yes, there will be times when a glut of uploads ensures that all ports are struggling to meet it, and there may be times when one port or another dips below the mark for particular reasons, but it really only becomes significant when the release team *notices* it because it's impacting our ability to process updates for testing, proceed with a multi-tier ABI transition, etc. 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 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. > The m68k ports autobuilder infrastructure is highly redundant and robust to > failures. Its secret lies in its team driven effort. Whereas other ports > might be handled by just a single or few persons, the m68k buildd admins are > a highly cooperative and communicative team. Therefore there's no big > maintenance overhead. Every buildd admin is only responsible for a small > number of buildds, but can easily jump in, if a buildd admin is on holiday > or for other reasons absent. Y'know, I think it's great that there is so much dedication to the m68k port from people willing to pitch in to make it work, because in a sense that's very much what Debian itself is about. But if you're going to present the existence of the team as evidence that distribution of the buildd workload doesn't have a cost, then I have to ask you who set the following Dep-Waits, what communication there was about it, and why one or more members of the m68k porter team are apparently completely oblivious to the ABI transitions currently going on, more than a month after libqt3-mt was uploaded to unstable and several months after libjack0.100.0-0 was uploaded: utils/hplip_0.9.5-3: Dep-Wait by buildd_m68k-poseidon [optional:out-of-date] Dependencies: libqt3c102-mt (>= 3:3.3.8) Previous state was Building until 2005 Sep 10 22:30:58 sound/xmms-kde_3.1-2: Dep-Wait by buildd_m68k-vault13 [optional:out-of-date] Dependencies: libqt3c102-mt (>= 3:3.3.3), libarts1 (>= 1.3.2), libjack0.80.0-0 (>= 0.99.0), kdelibs4 (>= 4:3.3.2-2) Previous state was Building until 2005 Sep 06 20:33:27 kde/smb4k_0.6.3-1: Dep-Wait by buildd_m68k-zeus [optional:out-of-date] Dependencies: kdelibs4 (>= 4:3.3.2-7) Previous state was Building until 2005 Aug 30 09:35:41 graphics/pdp_1:0.12.4-3: Dep-Wait by buildd_m68k-kiivi [extra:out-of-date] Dependencies: libjack0.80.0-0 (>= 0.99.0) Previous state was Dep-Wait-Removed until 2005 Aug 20 04:31:54 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. 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... > 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. > - 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature