Re: Questions for all candidates
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
Reply to: