On Tue, Feb 28, 2006 at 09:57:07AM +0100, Marc 'HE' Brockschmidt wrote:
> | The Delegates are appointed by the Project Leader and may be replaced by
^^^^^^^^^^^^^^^^^^
> | the Leader at the Leader's discretion.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "Replacing delegates on a whim" is not really an option, so that fear has
> no basis.
According to dict, discretion means the "freedom to act or judge on one's
own"; presumably we wouldn't elect a DPL who was subject to acting on
a whim, but it remains an option.
> > In the end, I don't think the difference is that important -- whether your
> > a maintainer or a delegate, it's no good if you go crazy and start doing
> > horrible things.
> ACK. But my concerns about this issue are based on the various
> conflicts some people had with the DAM and the ftp-team in the past -
I don't think worrying about past problems is much use -- we've got plenty
of current ones to worry about, after all; in particular, I don't think
there are major ongoing problems with either of those roles that warrant
singling them out.
> These problems were only fixed when the respective people chose
> developers to support them in doing their task, after a long period of
> whining, flaming and using nice language for each other.
The new new-maintainer process was begun when the DAMs at the time
refused to work until the rest of the project found some way to assist
them, resulting in the creation of the AM and FrontDesk roles; the ftp
assistant positions were created when ftpmaster found the time to update
the dak code to make that separation feasible. Neither of those changes
could reasonably have been been made without the active and continuing
cooperation of the people already in those roles -- so casting the problem
as one that was resolved as a result of whining and flaming each other
seems to me to misunderstand how that resolution actually came about.
Note that the DAM role is explicitly listed in 8.1(2) as being a
delegated position, and would be part of "speaking on behalf of Debian"
in my theory anyway.
> One can believe that if teams/persons who lead to such problems would be
> delegates, the DPL would be able to appoint people to help them, even if
> they don't have the time to search for fitting candidates.
The DPL can encourage people to help out anyone anyway; and I expect any
requests from the DPL for access to particular information that's not
readily available would be replied to fairly quickly. TTBOMK, that's
happened fairly consistently the past year, though obviously I'm not
privy to everything the DPL's been told.
> But anyway, I dislike the idea that a large part of our Project
> resources are managed by people who are not delegates of the only
> elected person in Debian, which is probably why I care about this.
As far as Debian's about producing a free operating system, most of
what's relevant are the packages we distribute via our mirror network
or on our CDs -- and every one of those is maintained by someone who's
not acting as a delegate.
Overview of that can happen though; it's just that it happens by either
convincing the maintainer that there's a better way of doing things,
or going through the technical committee, rather than the DPL being able
to make a decision at their own discretion. I don't have any particular
opinion on how the membership of the technical committee should be
managed; at present it's a somewhat strange combination of answering
to itself and answering to the DPL, but that could be changed if people
think a broader endorsement of its members would be valuable.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature