Re: Debian needs more buildds. It has offers. They aren't being accepted.
Scripsit Don Armstrong <don@donarmstrong.com>
> On Mon, 23 Feb 2004, Henning Makholm wrote:
> 1) Two months is from December 23rd-ish to now.
> 2) If I can read the code correctly, time to rejection is also counted.
As far as I can see, the queries for the "waiting for DAM" line
(except the first column) all include "WHERE newmaint IS NOT NULL AND
...". The should mean that only recent *accepts* count.
> It's quite possible that the time to accept|reject has a median of 57
> since the sample size is only 16...
Hm, 16 is the number of NMs *currently* waiting at the DAM stage [1],
not the sample size - the public database shows 21 new maintainers
being *accepted* since December 23.
> http://cvs.debian.org/newmaint/index.wml?cvsroot=webwml
Ah. If I try to do the median computation manually, I get the following
processing times for the 21 recently accepted maintainers:
12d 13d 13d 14d 16d 17d 17d
20d 25d 1m9d* 1m26d 1m29d 2m20d 2m24d*
2m29d 3m13d* 3m18d* 4m10d* 7m5d* 1y2m21d* 2y7m14d*
The raw median of these numbers is 1m26d = 57 days, just as the
statistics page claims. So I withdraw my hypothesis that the
statistics is buggy.
The 8 asterisked counts above are for records with logged traces of
non-trivial things happening in the DAM phase. If we ignore them, the
median instead becomes 17 days.
Though non-buggy, the statistics is still misleading, in the sense that
it is not a good basis for discussing whether there is a problem with
too long waits in the DAM phase. The around-17 days in the "standard"
case tells quite a different story than the overall median of 57. And
even 17 is probably higher than the usual performance of the process,
because the sampling period comes right after a holiday.
> Obviously feel free to suggest something that makes more sense and
> accurately reflects the dataset with patches.
I have no really good ideas. The fundamental problem is that the
really interesting [2] number cannot really be produced mechanically,
namely the amount of time the applicant sits waiting for action from
Debian's side rather than the reverse. Even if all emails in each NM
case was cc'ed to a database (awkward, easy to forget), it would be an
AI-complete task to distinguish between "Here are your answers. Over."
and "Thanks for your mail. I'll respond to it Real Soon Now".
We can *bound* the interesting number for the DAM case by 17, by
counting as above. That is low enough to convince me that the DAM
phase, contrary to what I believed, is not a serious bottleneck.
However, my computation is not one that can be automated, and it would
be impossible to establish a similar bound for, say, the T&S phase.
[1] I haven't quite figured out why there are 21 NMs rather than 16
listed for the DAM stage at <http://nm.debian.org/nmlist.php>, but
it appears to be a bug in index.wml: 'application_ok' in line 116
should be 'da approved'. That would make it match the
corresponding query in nmlist.wml.
[2] At least, interesting to impatient, soundly aggressive applicants
like me.
--
Henning Makholm "... and that Greek, Thucydides"
Reply to: