On Sun, Oct 31, 1999 at 03:09:31PM +0000, Edward Brocklesby wrote:
> This hopefully solves one or two problems we have identified in Debian,
> namely closed teams (new-maintainer, ftp maint etc.), stagnation of these
> teams, and the current issue of new maintainer being closed.
A proposal never solves anything. The only way to solve things is to
actually get off your butt and /do/ stuff. </Guns don't solve things,
people solve things>
> Please offer sensible, well considered, useful comments. Replies from
> rude, abrasive people (you know who you are) will be ignored.
``If you agree, that's cool. If you don't, go away.'' Yay.
Content-Description: Debian constitution changes
> [...]
`...' isn't a very good description of where these ammendments should
be added.
Okay. That about does it with the style objections. Onto the substance.
[In section 8.1, Powers (of the Project Leader's Delegates, add:]
> 3. The Project Leader's Delegate(s) may decide not to admit any new
> Developers (close the New Maintainer process), until the next
> release of debian, provided Developers are in favour of this
^ Debian.
> by a 3:1 majority. New Maintainer may be reopened either when the
> Developers agree to do so by a 3:1 majority, or the next version
> of Debian has been released. New maintainer may be closed for longer
> than this time only if a General Resolution is passed.
This isn't a restriction on delegates in general, only on the new maintainer
team. As such, if anything, it's more appropriate in the guidelines for
that team.
Also, this explicitly contradicts section 8.3, which says:
Delegates may make decisions as they see fit, but should attempt to
implement good technical decisions and/or follow consensus opinion.
Ummm. A General Resolution is actually easier to get than a 3:1 majority,
so requiring two votes, one for `close n-m', and another for `keep it
closed' is pointless bureaucracy.
Of course, this whole thing is pointless bureaucracy aimed at punishing
people who've donated their time to the project because they're just
not being conscientious enough, dammit, so that's proabably a pretty
weak objection.
Next, consensus at the moment seems to be more that closing n-m isn't
actually a particularly good or useful thing. Sure, it'll probably
happen again that there aren't enough people with enough time to keep
it going, so it might stagnate again, but deliberately closing it is
probably a mistake. So codifying it as something that we might do in the
constitution is a mistake for that reason too: it gives such a process
undeserved legitimacy.
> [...]
> 8.4 Composition
> 1. Any critical package or system team (e.g, the New Maintainer team,
> the FTP Admin team, any Essential package's maintainers) must have
> a reasonable number of active members at all times.
Why are these `critical'? What of boot-floppies, base system maintainers,
CD-ROM people, and so on? Also, if these packages are so critical, how
have we managed to cope with dpkg's primary maintainers essentially
disappearing for months on end?
> 2. If, for any reason, it is not possible for a reasonable number of
> members of any team to be active, the Project Leader, one of
> the Leader's Delegates, or a member of the team must appoint
> enough members to ensure there are at least two active.
Who will they appoint them from? If no one /wants/ to maintain dpkg,
you're not going to get any active maintainers, no matter how much you
yell and scream that they must do it, damn it. And if someone does want
to maintain (fix, enhance, whatever) dpkg, they will, as Wichert and
Ben have demonstrated.
> 3. All mailing lists for a particular team must be open, unless
> the Developers agree that it may be closed, by a vote with a
> majority of at least 3:1, or the Project Leader gives permission
> for the list to be closed, and no Developers object to this.
More pointless bureaucracy. People will communicate however they see fit.
> 4. An "Active" member shall mean a member who, in any given day, would
> be able to take suitable action on any situation relating to that
> particular team.
`would be able to take action'? So, ``Sure, I'd be able to do this,
but I don't feel like it this month, so get lost. I'm going to the
bar.'' would still make an active member? And ``Sorry, I can't do this,
my computer with my GPG key on it crashed and needs a new motherboard,
which I'll get in a couple of days when the shops open'' would be an
inactive member, requiring new people to be added to the team, right?
> 5. "Reasonable number" shall mean either the amount of people required
> to handle all issues relating to that team, or two, whichever is
> greater.
Of course, if you've got the right person, one is enough to handle all the
problems relating to a package. If you don't, a dozen might not be enough.
> 6. An "open" mailing list shall mean a mailing list to which anyone
> can subscribe to and read. The list may restrict who is allowed
> to post to it (a "moderated" list). The list must be archived
> in a publically accessible place, for a period of at least two
> years.
Of at least two years? So we'd better not run out of disk space for our
list archives, or the constitution will rap us on the knuckles? Bad
developers. Naughty.
Feh.
This doesn't do anything to address the real issue (getting
new-maintainers back on its feet), and only seems to give people something
to point to when whining about how everyone else isn't doing everything
for them.
We're meant to be about freedom as much as openness, remember. That
means /not/ having heaps of rules for everything that might happen.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpRBnYhTILKs.pgp
Description: PGP signature