Le Jeu 6 Avril 2006 00:17, Thomas Hood a écrit : > Pierre Habouzit <madcoder <at> debian.org> writes: > > the whole NM process is very frustrating as a candidate, because > > its slow, administrative, … we should do some efforts about that. > > Especially, the most negative point of NM is that it's not a FIFO, > > and that is MORE than painful for the applicant. > > I found it more frustrating not having any idea when the process > would be finished. That's why I propose a time limit. I wouldn't > care if others finished before I did; I'd just like to know that I'd > be done by a certain date. > > > 1) NM has to become a FIFO at each step: AM assigning, DAM > > verification, ... because this is *predictable*. > > I have no objection to the idea of requiring FIFO processing. > However, there can't be a FIFO where AMs are concerned since they > aren't a single resource. I'm assuming that AMs will continue to be > assigned to particular applicants in the future. sure, but looking at the people that have an AM for very long, why it took them so long time (because of the AM or the NM) is a good thing. and with the widely readable (restricted to AM's) mboxes/... another AM can take the NM process over, or the NM can be put on hold from the FD. I propose a preemptible association between NM and AM, so that an AM cannot be "blocked" because of an applicant that sleep(forever);. Honnestly, the real problem I see in NM, is that in that process, any AM is replaceable (in a Fordism [1] sense) and that nothing can reschedule an application that takes ages to allow those that are fast to go through. We must be able to make AM replaceable. The AM that takes a looooong time to write their report ? please ! Don't be kidding me, that can be written each step after the other, and nothing prevents the different parts of the report to be written by different DD, gpg signing is our friend here. > > 6) we should NEVER put any restrictions on time of any sorts. the > > point 1) sets the rules: either you are the one that spent the > > most time in that step, and you are the next to be processed, and > > thanks to the wonderful work of FD, you know that will happen. > > > > either you don't qualify, and you will be put on hold (with an > > explanation) or freezed (on your own request). > > Or you are qualified but you wait an indefinitely long time for an AM > to write your report. But perhaps that is something that does not > happen very often. What I meant, is that with some "time" counter beside the NM name on status.php, you can *look* at anormal cases, and work on them. Anormal cases will allways be the last ones in each task, and it will be easy for every one involved in the NM process to check why those cases are going sooooo wrong. and If you want an estimate of the time it'll take, you only have to sum the "worst" times on each steps. one's gonna give you the same answer on "when will I become a DD" as to the question "when do we release ?" : when you are ready / when ... In fact, you answered me to the parts of my mail where I basically propose to makes nm.d.o/status.php more transparent, sth that has two columns: left candidates that are here, annotated by their "NM time" (like in CPU time for the process, and not like in REAL time). and in the right column, candidates that are on hold/freeze for that "level". it's basically nothing really new, but lookin at the left column (ignoring border cases) just makes you understand in which shape the queue is, like ftp-master.d.o/new.html does for packages. [1] http://en.wikipedia.org/wiki/Fordism -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpqCX75Ajxp9.pgp
Description: PGP signature