Re: QUESTIONNAIRE: Debian Project Leadership
overall, i'd probably vote for you if it wasn't for the fact that you're
against having non-free in the debian ftp archives. in fact, i'd be
tempted to vote for even knowing that you're against non-free, because
the majority of developers would probably vote down any attempt to
remove it. you make a lot of sense on most issues, but are stubbornly
pig-headed and ignorant on some others :)
you also did a good job at the thankless task of Treasurer. it's a crap
job, but somebody has to do it, and you did it well with regular reports
and updates and generally showed good organisational skills.
IMO, the fact that you're confrontational and opinionated is a good
thing. the DPL should take a far more active and front-line role, and
set the agenda (for action and for debate).
On Sun, Feb 02, 2003 at 05:58:40PM -0500, Branden Robinson wrote:
> ---CUT HERE-----------------------------------------------------
> 1. Rank the following possible functions of Debian Project Leader in
> order from most important to least important by placing a digit
> between the brackets to the left of the item. Use "1" as the most
> important item(s), with larger integers reflecting less important
> items. You can give two items the same number to reflect a tie.
> Leave blank items you consider unimportant or not appropriate for
> the role of DPL.
> [ 3 ] attending trade shows and conferences
> [ 1 ] resolving disputes internal to the Project
> [ 2 ] representing Debian to trade associations, businesses and NGOs
> (non-governmental organizations)
> [ 6 ] drafting and implementing internal procedures for the Project
> that aren't already well-defined
> [ 4 ] appointing delegates per the Constitution
> [ 7 ] fixing bugs in packages that no one else will fix
> [ 9 ] cash fundraising
> [ 8 ] acquiring donations of bandwidth, equipment, and hosting
> [ 5 ] mentoring other developers
> 2. Rank the following past and present DPLs in order of greatest
> effectiveness to least effectiveness (use "1" for the most effective
> leader(s)). You need not have been a Debian Developer during the
> term a Leader to express an opinion here (though knowing who they
> are and what they did as DPL definitely helps). You can give two
> people the same number to reflect a tie. Leave blank people about
> whom you feel you cannot form an opinion.
> [ 4 ] Bdale Garbee
> [ 4 ] Ben Collins
> [ 1 ] Bruce Perens
> [ 3 ] Ian Jackson
> [ 2 ] Ian Murdock
> [ 4 ] Wichert Akkerman
> Comments (why did you rank these people as you did?):
Bruce got a lot of stuff done, he might have annoyed a lot of people
from time to time but he was an extremely effective and capable leader.
Ian M founded the project. Ian J got the constitution completed, but
was pretty much non-existent apart from that.
Wichert & Ben didn't really achieve very much. Bdale hasn't done much
more (a shame, i voted for him last time...and will probably vote for
him again if he stands for re-election). i think this is mostly because
all three have had a deliberately laid-back, hands-off policy. while
this isn't entirely bad, i don't think that it is a good thing.
a leader should have a vision, and inspire a sense of direction - even
if the direction s/he inspires is "no F-ing way, i'm going the opposite
direction!". i.e. it's not enough to just sit on the fence, a leader
has to make choices, and provoke action or reaction.
> 3. True or false: the New Maintainer system is still broken.
the DAM is a bottleneck with effective veto power over who gets in.
friends and friends of friends get approved immediately, as does the
occasional "famous" or well-known developer who wants to join, but
everybody else waits forever until they give up in disgust.
actually, it's worse than a veto - he just ignores applications he
doesn't like so that you don't even have a right of appeal - i.e. "no
decision has been made against you, so what are you whinging about?"
this has been an on-going problem (an open secret) for years that all
DPLs so far have ignored - probably because they're scared it would blow
the project apart to rock the boat and try to do something about the
fact that beneath the veneer of a constitutional democracy, there is a
not-so-secret cabal that really runs debian.
but this is one pile of shit that needs to be stirred, no matter what
comes of it.
> 4. True or false: we should place more emphasis on architectures that
> have a lot of users.
pragmatism wins. we shouldn't stop anyone from working on unpopular
arches if they want, though.
> 5. True or false: release management in this Project is a big problem.
debian needs to understand that it is an internet-based distribution,
and that the current stable release schedule is inadequate.
we need to make regular (monthly or bi-monthly) snapshot releases of
whatever is in unstable. the base system should be split off from the
rest of the package pool and tested thoroughly. this gives a tiny
subset of packages to test...then a new base installer set can be
produced whenever needed via smart scripting (most of which already
exists in the boot-floppies package)
the snapshot can be released with the last known working "base" system &
installer plus a /pool/ tree (on multiple CD or DVD images as required)
to install/upgrade the rest of the packages from.
i'm not sure what to do about stable. maybe with regular unstable snapshot
releases, the pressure will be off and we'll get less complaints about
the time between releases.
testing was a good idea that just didn't work. it is less stable and
less secure than either stable or unstable. dunno if it should be
scrapped or not, but it doesn't do anyone much good.
> 6. True or false: there are too many inactive developers.
for the most port, i'm one of them these days. it's hard to get
enthused about a pretend democracy that's really run by a cabal.
> 7. True, false, or not applicable: the Debian Project Leader should see
> to it that inactive developers are placed on notice that they will
> be dropped from the Project, and then if they do not become active,
> "expire" them from our ranks.
one day an inactive developer will become active again, and they
shouldn't have to go through the whole New Maintainer process
(especially with the current DAM's effective veto).
> 8. True or false: the concept of "one maintainer per package" is
> outmoded, and packages should be maintained as more of a group or
> communal process.
some packages are complex enough to require multiple packages. it
should be up to the maintainer(s) to sort out.
> 9. True or false: the Debian Policy Manual and Bug Tracking System
> should be used together as a "stick" with which to compel
> uncooperative maintainers to change the way they maintain their
buggy packages should get bug reports, but it's not good to see a bug
report as "punishment". it's feedback, some of it useful, some of it
> 10. True or false: the Debian Project is biased against people who do
> not speak English fluently.
false. well, not deliberately biased, it just happens that english is
the common language of the project.
> 11. True, false, or not applicable: there is not a lot that we can do
> about the Debian Project being biased against people who do not
> speak English fluently.
> 12. Should the DPL attempt to build consensus among a small group of
> experts or among the whole project before taking a major action, or
> should he go it alone? Mark one.
> [ ] build consensus among a small group
> [ 1 ] build consensus among the whole Project
> [ ] take unilateral action
> 13. Rank the following possible traits of Debian Project Leader as
> assets (with an "A") or liabilities (with an "L") between the
> brackets to the left of the item. Leave blank items you consider as
> having no bearing on the role of DPL.
> [ A ] a high level of visibility as a "regular developer" on
> internal Project mailing lists
> [ A ] a high level of visibility as Project leader on internal
> Project mailing lists
> [ ] a high level of visibility in Debian-related IRC channels
> [ ] a preference for reading prepared statements over extemporaneous
> presentations at public gatherings
> [ A ] a preference for brokering agreement behind the scenes between
> conflicting parties
> [ A ] a preference for brokering agreement in public between
> conflicting parties
> [ A ] long, flowing hair
> [ A ] a beard
> [ A ] a sense of humor
> (Those without the last item need not mark the last three.)
> 14. True or false: the Debian Project Leader should attend as many trade
> shows and conferences as possible for him or her.
geek conferences are important, trade shows not so important.
> 15. True, false, or not applicable: Debian Project funds should be
> spent on getting the Debian Project Leader to as many trade shows
> and conferences as possible when corporate sponsorship is
> 16. True or false: the Technical Committee is operating as intended
> under the Constitution.
> 17. True or false: a simple majority of voting Debian Developers should
> be sufficient to modify the Debian Free Software Guidelines.
> 18. True or false: a simple majority of voting Debian Developers should
> be sufficient to modify the Debian Social Contract.
> 19. Should decisions about DFSG-compliance be made on the debian-legal
> list, or should we have a more formalized body for making such
debian-legal is good enough in almost all cases.
> 20. True or false: under the current Constitution as written, a simple
> majority of voting Debian Developers is sufficient to modify the
> Debian Social Contract and Free Software Guidelines.
> 21. Mark the statements below that accurately (if not precisely) reflect
> your opinions with an "X" between the brackets. Note that these
> statements are wide-ranging in nature. If you have insufficient
> context upon which to ground an affirmative answer, leave it blank.
> Where I consider it important to determine what the respondents to
> this questionnaire *don't* believe or agree with, I have supplied a
> contrapositive statement. Feel free to elaborate on your answers in
> the comments section.
> [ ] The DPL should not waste his time on arguments about the
> Constitution, Social Contract, or DFSG.
> [ ] The DPL is always perceived as the DPL, even when he or she is
> not sending mails from "email@example.com" or providing
> evidence of his or her leader status elsewhere in mail
> messages he or she sends.
> [ ] The person elected to the office of DPL has a special
> responsibility to keep his or her mouth shut on potentially
> inflammatory issues, except when acting explicitly as DPL.
> [ ] The Debian Project will only get as good a DPL as it deserves.
> [ ] Everything in Debian main should be treated as software under
> the DFSG, even if it isn't software by some definitions.
> [ ] We let too much stuff that violates the spirit of the DFSG
> into main.
> [ ] The debian-legal list is infested with a bunch of nitpicky
> nitwits who give the Project a bad name and keep Debian from
> being as good as it could be by rejecting software from main
> for no good reason.
> [ X ] A good Debian Developer doesn't necessarily make for a good
> Project Leader.
> [ ] Debian should toss the DFSG and adopt the Open Source
> Definition (OSD) instead.
> [ ] Debian should delegate license interpretation to the Open
> Source Initiative (OSI) [maintainers of the OSD].
> [ ] Debian should stop distributing the non-free section.
> [ X ] Debian should keep the non-free section even if it dwindles to
> the point where there is nothing interesting in it, in the
> event that important new non-free software appears that our
> users might want.
> [ ] Our twin priorities of "our users" and "Free Software" are
> sometimes in conflict with each other.
they're not mutually exclusive.
> [ ] The primary purpose of the Debian Project should be to supply
> a high-quality operating system to as many people as possible.
> [ X ] The primary purpose of the Debian Project should be to supply
> a high-quality, Free operating system to whoever is interested
> in it.
> [ ] The Debian Project is an insufficiently welcoming environment
> to female geeks and computer professionals.
geeks are geeks regardless of gender. some are obnoxious boors, and
some are shrinking violets and most are in between - this is true for
all 5 sexes (i.e male, female, neuter, indeterminate and other).
> [ X ] The DPL should step in to mediate disagreements between Debian
> Developers and upstream developers, as recently happened with
only when there's no resolution in sight.
> [ X ] The Debian Project should work with SPI or some other
> organization to try and see that its needs and goals are
> respected, or at least not meddled with, by governments.
> [ X ] Debian Developers are substantially better at critical
> thinking and logical reasoning than the general populace.
> [ X ] The migration of murphy from qmail to postfix was a good
> [ X ] The migration of murphy from qmail to postfix was important.
we need more anti-spam rules on all debian mail servers. almost all of
the spam that makes it through my own filters (to be trapped by my
SpamAssassin) comes in via debian lists. we should have more local
access rules, use more RBLs, and have better filtering in general.
i used to be active on debian anti-spam stuff (e.g. creating procmail
rules for smartlist's rc.spam) but gave up a few years ago when it
became obvious that nobody with the level of access required was at all
interested in the spam problem.
> [ ] Being elected Debian Project Leader is primarily a reward for
> good work.
> [ ] The Debian Machine Usage Policy (DMUP) needs to be revised.
> [ ] Revising the DMUP is important.
> [ X ] Voters in the Debian Project have a responsibility to make
> themselves well-informed about the issues before casting a
> [ X ] There should be no one in the Project with
> extra-constitutional power; that is, Debian keyring
> maintenance, archive administration, system administration,
> and so forth should all be formally delegated positions by the
there should also be multiple or backup people delegated where it makes
sense to do so.
furthermore, anyone who refuses to do the job (or part of it) that they
volunteered to do should gracefully step aside and let someone else do
it. this doesn't necessarily mean that they should be removed
permanently from their position, it means that they shouldn't interfere
when someone else volunteers or is appointed to do what they won't.
keyring maintainence and DAM are two obvious examples where this is
necessary. also NMU releases of packages.
> [ ] Making the Debian keyring maintainer, archive administrators,
> and system administrators DPL delegates has creates a
> potentially dangerous situation for which there is no analogue
> under the current situation
> [ ] The DPL has more important things to worry about than who's
> delegated to do what.
> [ ] People who capitalize the phrase "Free Software" are annoying.
> [ ] The Free Software Foundation is run by a bunch of crazy hippie
> communists, and Debian is being taken over by more of the same.
> [ ] The Open Source Initiative is run by a bunch of Christian
> fundamentalist right-wing gun nuts, and Debian is being taken
> over by more of the same.
> [ ] I deeply resent whimsy intruding into this questionnaire.
> [ ] A person who lost the DPL election twice shouldn't think about
> running again.
> [ ] No one who lost the DPL election was ever subsequently elected
> [ ] No one who lost the DPL election twice was ever subsequently
> elected DPL.
> [ ] Bdale Garbee is unbeatable.
> [ ] Bdale Garbee has disappointed me.
> [ X ] We should elect a DPL based on his or her platform and
> contributions to the project, not based on personality issues.
> [ ] A DPL candidate shouldn't make promises in his or her
> [ ] We should elect a DPL who reflects who we want to be, even if
> they don't reflect who we are.
> [ ] DPL elections are essentially popularity contests.
> [ ] There is nothing we can do about the above statement; it's the
> nature of the beast.
> [ ] Circulating this questionnaire proves that you're unfit to be
> Project Leader.
> [ ] Circulating this questionnaire demonstrates leadership.
> [ ] Circulating this questionnaire is a cynical attempt to
> manipulate the electorate.
> [ ] Debian Developers should publicly and prominently campaign for
> the person they'd prefer to see as Project Leader.
> [ ] Debian Developers should keep their DPL preferences to
> [ ] DPL campaigns have increasingly come to adopt traits of
> conventional politics.
> [ ] I find previous statement true and not a cause for concern.
> [ ] The DPL can barely wipe his nose without consensus. (The DPL
> is essentially a figurehead without much real power.)
> [ X ] Debian's effort at a constitutional system of governance
> has been a failure.
> [ X ] The Debian Constitution and the apparatuses instituted by it
> are basically instruments of last resort, called into play
> when our traditional methods of operation fail.
> [ ] We'd be better off with a few hundred fewer Developers.
> [ X ] We'd be better off with more Developers.
> [ ] Debian distributes too many packages; we should narrow our
> [ ] Branden Robinson is a non-free flame burning bigot.
> [ ] Branden Robinson is prejudiced against the French.
> [ ] Branden Robinson is prejudiced against the American
> [ ] Branden Robinson doesn't know when not to make jokes.
> [ ] Branden Robinson has a lousy sense of humor.
> [ ] Branden Robinson's sense of humor is not important, no matter
> how good or bad it is.
> [ ] Branden Robinson has gotten better at not flaming people over
> the years.
> [ ] I haven't really paid attention to whether or not Branden
> Robinson has gotten better at not flaming people over the
> years, but it doesn't really matter because I'm not going to
> vote for him anyway, even though I'll claim that I won't vote
> for him because he flames people.
> [ ] Branden Robinson wrote a questionnaire that was way the hell
> too long.
> [ ] The number of occurrences of the string "Branden Robinson" in
> this questionnaire proves that he's an egomaniac.
> [ ] An egomaniac can make a good DPL.
> [ ] We already *have* an egomaniac for a DPL.
craig sanders <firstname.lastname@example.org>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch