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

["Jamin W. Collins" <jcollins@asgardsrealm.net>]

On Sun, Jul 20, 2003 at 12:01:33PM -0600, Joel Baker wrote:
> On Sun, Jul 20, 2003 at 11:17:23AM -0600, Jamin W. Collins wrote:
>  
> > Could a GR not be used to set/change the operation requirements of a
> > delegated office, mandating operation guidelines/timeframes?  Seems
> > to fall in line with 4.1(3).  The DPL has still not provided a clear
> > statement about the delegated responsibilities or authority of the
> > DAM.
> 
> It could, but frankly, I don't find the de facto authority of the DAM
> to be the problem with the system; only the lack of transparency and
> the delays involved in it (and the latter might be perfectly
> explained, if the former were not true, for all I know).

It's a mandate concerning the transparency that I was mainly getting at.
Right now, DAM doesn't appear to be required to document anything he
doesn't feel inclined to.  Based on his current documentation, that
doesn't appear to be much if anything.

> > And if both the DAM and DPL pointed ignore this dissatisfaction?
> 
> Then the most obvious (but long term) option is "elect a DPL with a
> different platform next time", for anyone who can vote on a GR. Sadly,
> nobody in the NM queue can actually do much about it, which I remember
> all too well. A GR probably wouldn't fix it significantly faster,
> unless it had a significant majority of developer support before even
> being proposed; otherwise, it'll bog down in endless discussions, most
> likely.

And sadly it appears many DDs don't see a significant problem with the
current situation.  Though, I have received private replies indicating
support for my stance.  I see continuous indication from those who seem
to think it's not broken that I should spend my time working to improve
Debian rather than continue what they seem to think is a pointless
tirade.  However, what these same DDs don't seem to get is that this is
an attempt to improve a very important part of Debian.  This is the
bottleneck that leads to all other improvements in Debian.

> > DAM needs to either step up and get the job he's been delegated done
> > or step down and allow someone else do the job.  Status quo is
> > broken, action needs to be taken, preferrably one that institutes
> > some guideline/requirement of how the job is performed.
> > Additionally, reasoning for application delay needs to be open to
> > public review, no more secret reasoning.
> 
> I agree, but most emphatically on the last point; I don't think people
> will ever stop griping over things, no matter how short or long, but
> if the reasons were documented and clear, I think the griping would be
> reduced, and many more folks would simply write it off - because they
> had confidence in what was said.

I believe they go hand in hand.  Clear documentation would almost
certainly lead to shorter queue times.

> This is one of the few areas in Debian which utterly lacks the open
> review which is crucial to oversight by the electorate - and that,
> more than anything else, is what tends to bother me about it. Without
> that information, the electorate (namely, all DDs) cannot make any
> useful decision as to whether the DAM needs to be replaced, given a
> helping hand (and what would help), whether something else is broken
> that the DAM can't fix and is doing his or her best to cope with...
> whatever.

The simple question is why is this allowed to exist, and why are so many
content with it staying this way.

> Unlike a recalcitrant maintainer, there is no way to NMU the DAM's
> work, no way to appeal a decision to the Technical Commitee (or any
> equivalent, other than the DPL), and we're currently in a state where
> the "buglist" appears to be a very large number of non-wishlist bugs,
> some of them very old even by our standards, with no maintainer
> comments.
> 
> If we don't accept this as status quo for developers (frankly, anyone
> with a buglist like that is facing MIA checks and/or involuntary
> package orphaning), why should we accept it from the DAM, which, much
> like something such as Debian-Installer, is more crucial to us than
> nearly any package in the distribution (frankly, IMO, *is* more
> important than *any* package; packages can always be rebuilt,
> replaced, or given alternatives - the DAM can't, short of very massive
> changes to our administrative infrastructure which I see no real cause
> to make).

So, it's fairly accurrate to say that if DAM were looked at as a
maintainer his actions and documented reasoning so far would be consider
recalcitrant.  That is if any DD treated their package maintainence the
way DAM treats NM queue processing, maintainence of the package could be
removed from them.  Yet DAM is allowed to continue to be unresponsive
and secretive.  DAM wields a considerable amount of abitrary power, 
provides little to no documentation, and has no apparent check or
balance.

-- 
Jamin W. Collins