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

Re: Work-needing packages report for Jul 11, 2003

On Sun, Jul 20, 2003 at 10:51:56PM +0100, Matthew Garrett wrote:
> Jamin W. Collins wrote:
> >If the DAM provided this level of attention to most any other
> >_volunteer_ job, I suspect he would be politely thanked for his
> >contribution and replaced by someone more able to perform the task.
> >Leaving applicants in limbo with no update for years at a time is
> >uncalled for and derelict.
> Someone who enters Debian is in a position to upload a package that
> could backdoor a very large number of machines. Attention to detail at
> the DAM stage is *more* important than pretty much any other decision
> making process in Debian. If the DAM fucks up even once, we lose
> massively.

There's that paranoia spectre again.  There is nothing that stops a
current DD from doing the exact same thing.  There is also nothing to
indicate that the above is DAM's reasoning for the extremely long
delays.  If an applicant isn't clearly trustworthy within 60-90 days is
another 9 months or more truly going to help?  It would be better (and
safer according to your argument) to refuse the application and let them
reapply later, or even state that as a reason for having the applicant
wait a longer period.  Instead we simply leave the applicant in limbo
without any update.

> >> The role of the DAM (among others) is very critical to the
> >> well-being of the Debian Project as a whole. 
> >And as such should be staffed by a responsive individual with the
> >time to peform the task.  The current DAM is neither.
> Is anyone appropriate for the task currently volunteering to do so?

Just because people aren't beating down the door to volunteer doesn't
mean there isn't someone that would accept the job and do a
significantly better job then the current one.  Hell, the position isn't
even open so I would hazard a guess that most people aren't volunteering
for it becuase it's listed as filled.

> We occasionally bitch about the length of time it takes the security
> team to produce an update for certain things, but it seems to be
> generally understood that it's taking that long because that's how
> long it takes. Without potentially compromising the entire project,
> I'm unconvinced that the DAM process could be made significantly
> faster.

I doubt the security team is as unresponsive as the current DAM.
Release of information/explainations have a way of creating
understanding.  The current DAM has release no information or
explaination for the current state of affairs, and based on past
performance isn't likely to.

Jamin W. Collins

Reply to: