Re: Questions for DPL candidates: casting the lead to fathom our course
On Sat, Mar 10, 2007 at 07:23:06PM +1030, Ron wrote:
[...background snipped...]
> So... with some background now in place, and given that some of the
> candidates have proposed in their platforms that we further accelerate
> the processing of NM applications to include people in the keyring,
> and that some have indicated their main reason for running is to
> increase the 'clout' of their own personal opinion on certain matters
> they don't feel they can manage through consensus building between
> equals,
For the record, I don't feel I am part of this group of "some of the
candidates" you mention here. I do not feel we should accelerate the
processing of NM applicants if that makes the quality of the NM process
go down.
AIUI, part of the reason why it takes so long currently is that the DAM
wants to make sure that the NM isn't going away after being a developer
for a few months. Obviously that doesn't necessarily have to mean that
going through NM has to take 3 years or so, but it does mean that
reducing the whole NM process to a two-month formality isn't possible.
After the DAM has accepted the application, it does indeed take quite a
while before the key gets into the keyring, and it would be nice if that
time could be reduced. This is a technical problem, however, and one
for which Joey Hess recently wrote something that could be a
solution[0].
> I'd like to hear the opinions of the candidates on what they think is
> the best way for us to manage our future growth in a sustainable way,
> without sacrificing our original dedication to technical excellence
> and developer freedom above all else.
I think we're doing this quite well, actually. Do you think I'm missing
something?
> Now that we have collaborative tools such as Alioth, which allow any
> developer to allow anyone they deem fit to have direct commit access
> to their work -- and leaves the ultimate responsibility for what
> happens there to that developer or team of developers who make signed
> uploads to the disto, do we still have the same pressures on filling
> the keyring with as many people as we can, as fast as we can -- or
> should inclusion in it be perhaps even more limited to people who have
> proven their judgement for what belongs in the archive at any point in
> a release cycle and what does not?
Do you mean whether we should ask prospective maintainers to become part
of a package maintenance team first before we allow them to join Debian
as a full developer? Or is it rather that you want them to show _some_
skill as a package maintainer, no matter how?
If the former, then I think this would be too strict.
If the latter, then I should note that this already is the case.
Starting a few months ago (IIRC), NM applicants must have some package
already in the archive, either through sponsorship or through group
maintenance/alioth.
> How do you think that moulding our membership in this way might effect
> our ability to better regulate our release schedules in the future,
> given that screwing up something which holds up a release and
> understanding what and how you screwed up is the general prerequisite
> for more reliably not doing so in future?
So you want maintainers to screw up first before you want to allow them
to become Debian Developers? ;-P
Seriously, I'm not convinced that "I screwed up before, and I know
better now" is a good guarantee for not screwing up. I've been known to
screw up package uploads at inconvenient times, too[1]; we're all human
beings, and mistakes do happen.
In that light, I don't think it's a very good idea to hold people back
for longer than really necessary.
> Do you think that increasing the number of people who've never been
> through a full release cycle for each new release and having those
> people actively uploading while we try to prepare one will make the
> job of RM as it currently exists an increasingly intractable one?
Perhaps; but I'm not convinced that "make NM harder" is the right
solution to that (potential) problem.
> Or should more of the responsibility for determining release
> worthy-ness be shifted to the developers sanctioning new uploads?
Not sure what you mean by that.
> Should we even freeze admission of new people to the keyring while a
> release freeze is in progress, assuming (and this is just an
> assumption on my part, I'd be interested in seeing some serious
> analysis to back this up before it was acted on) that they are the
> most likely to be uploading new packages with new bugs at a time when
> that is least desirable.
No. Certainly not. During a freeze, getting a package out of unstable
requires the ACK of an RM; this is the time when any Debian Developer
can do the least amount of harm.
> Do you think that (in a somewhat perverse way) this would encourage
> more of the people in the queue at that time to help accelerate the
> release?
Eh, probably. But I don't think that'd be worth it.
> Do you think that would in turn promote a new era of 'self-selection'
> from some of those applicants?
Dunno.
> Do you think we should be continually raising the bar of skill
> required as the project as a whole refines its best practices, or
> should we be lowering it to match the average level of people now
> interested in contributing as our mass market appeal grows?
We should certainly not lower the bar. We may want to allow people with
different skillsets than just "I know how to create a package", but that
doesn't mean lowering the bar. I do think it makes sense to raise the
bar from time to time, too; for instance, when I joined up, there was no
alioth, no pbuilder, no piuparts, and so on; but I do ask my NMs
questions about these tools, and expect them to understand them.
There's nothing wrong with that. Debian evolves, and so must its
maintainers and contributors.
> Lastly, and in the context of all this, how do you see that the role
> of DPL must change to keep it relevant to an increasing body of
> volunteers that cannot in fact be led by simple proclamation from the
> top. We've seen numerous times now that a DPL (or GR) which insists
> on something that is not backed up by consensus only leads to
> increased divisiveness in the project and less real work being done by
> those who's opinion has been ignored or defiled.
I agree; and this is part of the reason why I'm standing up to be a DPL.
I do *not* think that a DPL should insist on making a decision if that
decision is not backed up by consensus. A DPL who tries that anyway,
will only create ruptures in our community, which is not for the good of
the project.
> How can we keep this role as one which guides us all through the clear
> water at the crucial points of navigation and avoid the politics of
> casting some people up on the rocks just to find out where they are?
> Especially when the role is mostly symbolic and its holder is only
> able to make small course changes before people start falling
> overboard en-mass or plotting a course of mutiny...
The DPL position is one of moral leadership. While a DPL cannot (in
practice) make hard and fast decisions, the real power of the DPL lies
in the fact that he is a voice that will be listened to.
A DPL should be someone who is able to understand the viewpoint of many
other people without forcing their opinion on something; he should be
able to "feel" the consensus before even discussing it. A DPL should
know when he's made an error, and be able to publically admit that. He
should have an opinion, but should also be able to recognize when his
opinion is a minority view, and act accordingly. Or, in the words of the
constitution:
``The Project Leader should not use the Leadership position to promote
their own personal views'' (§5.1.9)
I'm not saying I have all the above qualities, but I do believe I
possess at least a fair share of them. I'm also quite sure a number of
other candidates do, although I'm not convinced of all of them.
[0] <http://joey.kitenet.net/code/jetring.html>
[1] <http://packages.qa.debian.org/n/nbd/news/20050805T114706Z.html>,
which closed #321280, severity grave
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: