On Thu, Nov 22, 2007 at 11:34:38AM +0100, Andreas Tille wrote:
> > We might be able to form a group and create a tool with such properties,
> > but it will take time. It takes longer if people sit around complaining
> > about how it's someone else's responsibility to take the initiative. It
> > isn't as good if you refuse to take the opinions and concerns of
> > experienced and knowledgable people into acount.
> Here we go again: Isn't this the canonical hen - egg - problem of Debian
> authorities?
("chicken and egg" is the usual formulation in English)
Another way of looking at it is "who compromises first?" Having
disagreements where both parties think they're in the right, and the
stakes keep getting raised isn't all that much better than if one side
keeps giving in completely.
Personally, I like the "baby steps" approach -- you make a small
compromise, then expect the other party to make a small compromise too,
and repeat. Sometimes the other party won't make even a small compromise
easily, of course, but even with that I think iterating incremental
improvements is the way to go.
> > You don't solve social problems by refusing to make reasonable compromises.
> > Having the software be written in a way that's comprehensible and able to
> > be modified to suit the needs of the people who are going to use it seems
> > emminently reasonable to me.
> Well, people sounds like plural to me.
Yes. If the keyring team were to include James Troup and Joey Hess,
eg, I'd be thinking it'd be worth having both jetring (written in perl,
which Joey's much more comfortable with) and, say, jytring (a compatible
python implementation, which James is more comfortable with), with the
keyring being fully auditable and manageable by both or either.
> Other people anounced to accept the existing tool in the
> language it was written in.
Not everyone cares about implementation language, that's fine too. They
might have other concerns to be addressed, or they might be willing to
just go with whatever.
> > I suspect you can get a hint from:
> Well, communication is not about fetching hints but stating clearly
> what is going on.
Well as per RFC760 [0], you should certainly state things clearly
yourself, but you should also be liberal in what forms of communication
you accept from others.
> > > The
> > > continuos discussion shows that a status report every second year might
> > Status reports like, say:
> > http://lists.debian.org/debian-devel-announce/2006/12/msg00010.html
> > http://lists.debian.org/debian-devel-announce/2007/03/msg00018.html
> > ?
> Yes, these reports are fine and we are happy about them. Unfortunately
> they do not cover the topic of turning single person tasks into team tasks
> and this is what we are talking about here. (Or did I missed something?)
RT lets other people track requests of DSA and keyring-maint; currently,
aiui [1], Raphael (hertzog@d.o) and Matt (taggart@d.o) are in that
category at least for DSA.
Both those issues were the "high priority" tasks that were precluding
doing a better job on either of the tasks and working on adding more
people. Since they've been done, though not without further urging from
the DPL, DSA has increased in size by 33%, eg.
Now, maybe you think adding a single person to DSA is stupid, because
ten, twenty or a hundred people should've been added. Personally, I
look at adding a single person as the first step in adding ten people;
and think it's probably better, both in risking less problems, and resulting
in better training for the new people.
Which gets me back to the whole idea of alternating small efforts at
compromising.
Some of the efforts I could see doing some good include:
- building a tool to let multiple people manage a keyring securely
and easily, with a focus on being auditable; obviously I think
jetring's a good effort at this, but it's still a long way of
being ready for use in keyring-maint. Maybe people should be
writing other tools though, in case jetring turns out to be crap.
Or maybe people should be auditing jetring to shake out the
bugs.
- volunteering to organise and manage keyring-maint requests;
making sure they're all in rt, making sure it's easy to act on
them, answer any FAQs (Q: my key's expired, here's my new one;
A: don't generate a new key unless it's compromised; extend
your expiry date)
- updating and maintaining the debian-keyring package, making
sure it stays in sync with the official keyring, and keeping a
proper summary of all the changes in the changelog (jetring-diff
might be some help there)
- making it easier to securely maintain debian servers without
requiring DSA involvement -- eg, by making it easy to install a
package to give all DD's a login, so setting up a porter machine
can just involve having a machine of the right architecture,
installing Debian, installing a package, and saying "here,
login!", or "send your ssh pubkey signed by your key in the
debian keyring to this address, then login!"
But if you want a favour from someone -- like access to some restricted
service -- you're much more likely to get it if either (a) that someone
wants to do you the favour already; or (b) you approach it as "Hi, I'd like
to help. There's a bunch of gruntwork that I think would help and that I
could do if you'd like me to. I'm not trying to change policy or get any
more say in how things work or become famous or whatever, just help out"
and actually mean it.
If neither of those are options, or you've sincerely tried them
and they just don't work out, the next easiest option is just to do
things yourself. You almost certainly have root on a machine of your
own somewhere, and any software that's already used by Debian can be
downloaded. What's more important? Getting the change you want made so
it's usable by other developers and users, or getting the change you
want made by the right people?
Cheers,
aj
[0] "In general, an implementation should be conservative in its sending
behavior, and liberal in its receiving behavior."
[1] http://www.ouaza.com/wp/2007/07/26/some-changes-concerning-dsa/
Attachment:
signature.asc
Description: Digital signature