[Thaddeus H. Black] > 3. If James' imperial rules are unacceptable to us, then the > alternative is to change the person in James' position. It has > been years since any other option was credible. We all know > this. This means dismissing James from his fortified posts of > Project power---and accepting the potential consequences of > converting a powerful James from a difficult friend to a > difficult foe.
[Thomas Bushnell] > It was my understanding that the new DPL would seriously consider > this possibility. It seems to have been simply ignored instead. As > usual. I assume the DPL has been working in the background to try to resolve this, as an public and open power struggle between the DPL and the people in key privileged positions would soon become very ugly, and affect the Debian project badly. How badly do you want the omelet? Are you willing to break the eggs, oven and the rest of the kitchen to get it? What do you expect would happen if the DPL team reassigned the privilege of for example ftpmaster, system administrator or key ring maintainer to other people? The new people would lack passwords, physical access and the cooperation of the original people. The current privileged people might refuse to acknowledge the delegation, and ignore the new people and the DPL. We could end up having to set up a separate infrastructure for use by the new teams, while the old teams keep the old ones, and in practice a forked Debian project where some people keep working with the original privileged people, and others work with the newly delegated privileged people. This, I believe, would be the consequences of an open and public power struggle between the DPL and the current key privileged people. I'm not sure it is a win for the Debian project on short nor long term. As the current people seem to be reasonable people, I believe it is better to start by discussing the issues and try to re-enforce the teams with new people to take some of the load off these overworked people and hopefully make sure we both get improved performance in the areas were the project is weak, and increase what I call the bus factor, aka how many people will have to be run over by a bus before the process stops. At the moment the bus factor is 1 or less for several key processes in Debian. I guess the first part of the solution is to get those in key privileged positions to realize that there is a problem. If they don't, all effort to solve the problem will be in vain. Next, one can start to discuss possible solutions, and try to work out how to implement one of them. As all people involved have lots of priority tasks on their hands, and I suspect the lack of transparency, redundancy and accountability is not seen as a high priority problem by the key privileged people in Debian, it will take a long time to get to a point where solutions become visible. (And do notice, I am not talking about James the person as if he was the problem or the only problem. I know James and most of the rest of the key privileged people in Debian (I do not know them all. :) as hard-working, overworked persons, and seriously believe they want and need help in finding a solution to these issues. Just "getting rid of James" might not solve anything, if he is replaced with the next well-meaning hard-working, overworked person. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
