Hi, > > 4. The DAM is : > > > > [x] a critical part of our infrastructure > > [ ] guilty of not rejecting people when they deserve to be > > That's possible, but I'm not sure it should really be the DAMs job to > exercise a veto on an NM candidate that has otherwise passed the > process.
Can you elaborate on what you mean by "exercising a veto"? Does that have any concrete implications or specific actions associated with it? In your opinion, is it ok for an application to take a year before it's fully processed, meaning, the applicant is either rejected or he gets his account? Where do you draw the line? Half a year is not ok but three months is? What do you think is or could be the role of the DPL in this? During the last week or so, a bunch of people have gotten their accounts created, after some months of stall. This is not the first time the process has stalled. In your opinion, is there a way to prevent this from happening in the future? What do you think about the fact that for all visible purposes there's a single person acting as Developer Account Manager? Is that a model that you agree with? > > [ ] too powerful, refusing to add some packages when > > the license was ok (example: apt-i18n a few months ago) is a > > shame. > > I can't really agree with this one either. Even if one feels that > apt-i18n was a bad call, that doesn't mean the FTP admins shouldn't > have the corresponding power. People are occasionally going to > disagree on specific decisions, just as they do with package > maintainers. My impression is that the question went along the lines of "should ftpmaster have the power to veto packages based on criteria other than DFSG-complainness" You can of course take the example to the extreme and ask if the ftpmasters should veto rm-rf (Description: upon installation this package with call 'rm -rf /' as root) from entering to the archive. I think the answer is obvious in that case (yes). The question applies to more realistic cases: what happens if someone decides to upload glibc-cvs... oh, bad example ;-) but I think you get the idea. I think the general point is that the organization page lists a lot of people in specific teams, but it doesn't say what these teams can actually do or can't do. Take for example the Security Team. Where does it say that the Security Team can make NMU without contacting the maintainer beforehand? The question is _not_ if you agree or don't agree with that policy. I'm also _not_ saying that there should be a listing of these teams' "powers", a list that can be thrown at them when they don't stick to it. The question is what do you think about that. If you wish, the question is how much bureaucratization do _you_ think is too much bureaucratization. > [2] Hello, Mr. President. LOL Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
