On Sun, Jul 20, 2003 at 11:17:23AM -0600, Jamin W. Collins wrote:
> On Sun, Jul 20, 2003 at 11:01:02AM -0600, Joel Baker wrote:
>
> > Or they are not quite so arrogant as to think they could pick someone
> > out of a hat who would *absolutely* be a better choice, which is more
> > or less what any meaningful GR would have to do (one directing the DPL
> > to select a new DAM, without saying who, is not terribly useful, IMO).
>
> 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).
> > So instead, we try to make it clear that we *are* dissatisfied,
> > without having to spend a lot of *everyone's* time on running a GR
> > that many folks might vote against on principle ("We shouldn't be
> > making this sort of decision for the DPL"), whether or not they think
> > the NM process has issues.
>
> 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.
Another part of the reason I don't consider a GR the appropriate solution
to this particular problem (at least, not yet).
> > If I thought a GR would actually provide a useful resolution to the
> > problem, I wouldn't hesitate to put one up. I don't, in this case,
> > mostly due to previous conversations. And so, instead, I'll restate
> > the offer that I'd rather try to do something useful to help fix it -
> > if anyone will say what *needs to be done*.
>
> 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.
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.
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).
--
Joel Baker <fenton@debian.org>
Attachment:
pgpJm6Kvk25VR.pgp
Description: PGP signature