[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions for all candidates


 > > 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.



Reply to: