[Wouter Verhelst] > Oh, and here's something else to ponder: Maybe, just maybe, James > has more time to go to Ubuntu below zero than he has to handle > keyring updates because he prioritizes by what gets the bills > paid. As most of us do, I suppose.
Yes, most of us have changing priorities, and am not able to follow up all our Debian commitments all the time. I am convinced this is the case with the keyring maintainer James as well, and that he will process the backlog as quickly as he can. But as we know that the priorities changes over time, and that some times real life or other commitments demand our focus from time to time, it is vital to plan and prepare for this, and make sure no privileged position in Debian depends on one persons priorities. And as keyring maintenance is a privileged position (I can not take over immediately it if James is not doing it), we need to make sure the processing of key changes do not stop when James am unable to handle the incoming queue of requests. Do we know how many requests are in the queue? Is the queue growing or shrinking? Is the current processing speed enough to actually empty the queue some time in the future? It would be interesting to know these things, and one way to make it possible for others to monitor the status of the keyring maintenance would be to make sure the processing is transparent. Is it? I do not know, but hope it is. If it isn't, it is very hard for others to take over if James suddenly is unable to process the requests at all. I believe it is important for Debian as a project to make sure the privileged positions have good redundancy. (I call this the bus factor - aka how many will have to be run over by a bus before the project/process/work stops. A bus factor <= 1 is very bad. :). At the moment, several of the privileged positions in debian seem to have a very low bus factor, and we should address this as a project to make sure the task being done by the people in these positions do not grind to a complete halt when their real world commitments take "too much" of their time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
