Re: my platform for Debian Project Leader
Previously Branden Robinson wrote:
> [please follow-up to email@example.com]
No, follow-up to debian-vote, it was created for this purpose.
> I cannot at present find a canonical list of current delegates.
I'm offline at the moment and the exact URL escapes me, but this list is
on www.debian.org and was created about 2 yaers ago.
> Delegates should serve for a term of one year, or until the
> next DPL begins his term.
I really have to object to this: a change of DPL should not mean that
every delegate suddenly needs to be re-appointed and the whole project
does not know what is going to happen. A delegate is someone the project
should trust, and a change of DPL is no reason to make that trust
suddenly disappear and require the new DPL to reappoint or appoint
> I would like to think that in many cases, a delegate could continue to
> serve out his or her year-long term even across a DPL transition, but
> I also believe that delegates must derive their status from the
> sitting Debian Project Leader, since this only makes sense.
Can you explain why? Compare it for example with judges in (afaik) all
legal systems. They are also not changed when the government changes
after an election.
> At the very least, I believe the current DPL delegates of Project
> Secretary, Release Manager, Debian Account Manager, and Debian System
> Administrators should be completely formalized under this process.
Release manages is, ever since Richard Braakman became release manager
about 2 years ago. If you look at the URL I mentioned above you will see
the exact delegation notice.
> My recent experience with LinuxWorld Conference & Expo, New York, 2001,
> gave me a few ideas about we can better handle this issue. In a nutshell,
> we had no one representing Debian with the coordinators of this event until
> less than two weeks before it occurred; as a result, Debian very nearly
> went without a booth at a major trade show. I do not consider this a good
> thing, since we had Debian developers in attendance and willing to
> represent us at the booth, answer users' questions, and otherwise put a
> face on the Project.
You did manage to pick the one bad apple here, in general things go a
lot better, and for the next LWCE arrangements are already being made.
> As Debian Project Leader, I intend to get into personal contact with as
> many board members of SPI as possible and attempt to persuade them to
> populate their board with people who are able to give some attention to
> their duties.
As you should know, the DPL is automatically an advisor on the SPI
board. (and I've been trying the same thing for some time as well fwiw)
> V. REVISION OF THE DEBIAN MACHINE USAGE POLICY
> When I first read the DMUP I felt it was a poor fit in places for
> Debian. I was told that many of its terms were lifted verbatim from an
> ISP's Acceptable Use Policy (AUP). As DPL, I'd like to appoint a team,
> including at least one representative from the Debian System Administrators,
> to draft a new one.
Didn't you volunteer to do that a while after it was introduced? I
remember nothing came of that.
> VII. THE #DEBIAN-DEVEL IRC CHANNEL
> As DPL, I'd like to see this channel's status officially recognized, and a
> position on the two subjects above formally stated. If #debian-devel is
> not to be substantively different from #debian, that is fine; a new channel
> can be created to serve the needs that (in my opinion) #debian-devel
> currently does, and with some access controls in place.
I'll object to this. #debian-devel should be like the debian-devel list:
open for developers, not closed. That is the way it has been since the
very beginning and I hate to see that change. Make #debian-private if
/ Nothing is fool-proof to a sufficiently talented fool \
| firstname.lastname@example.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |