Re: Questions for DPL candidates: casting the lead to fathom our course
On Sat, 10 Mar 2007, Ron wrote:
> Some years back now, the DAM's of the day announced they would be
> suspending the processing of NM applicants while we figured out how
> to deal with this change to our environment, and likewise to the
> type of people presenting themselves as applicants.
>
> Rather than listening to that advice, a number of movements were,
> well, put into motion, to instead _accelerate_ the number of new
> applicants that the project took in.
I don't know to what movements you're referring exactly. It's at that time
that I proposed the sponsorship mechanism that we still use nowadays. It's
a good way to take the load from DAM. Because the DAM tried to make sure
that you had some skills and competences, but they couldn't simply
continue doing like they were because there were too many candidates and
Debian grow too big for them to know the package that the candidates have
been working on, etc.
And the whole formal NM process got formalized a bit later based on this
new way to check the skills of an applicant. I don't see anything wrong
here.
> Causality is always a tricky thing to put your finger on, but since
> that time, it seems fairly clear that we've experienced a rise in
> both social troubles, and, more importantly IMO, the number of
> technical issues that people have tried to force through social
> mechanisms (ie. a majority vote on a GR) rather than by building
> consensus on the most technically optimal solution for all
> interested parties.
You'll have troubles relating the problems to the growth of number of DD.
We had serious social troubles with DD that were in Debian even before the
NM process got introduced. We had serious troubles with people who are not
even DD.
The increase of troubles is directly related to the growth of the project,
not especially to the growth of number of DD.
There are some discussions on which kind of persons are selected by the
current NM process. I don't have the answer, but I surely believe that's
it not worse than the selection that we had before.
> 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?
Hey, this is a good idea. We should certainly include more questions
related to our release process in the NM process. And maybe we should
require them to accept the duties of working with the release team for any
changes that their packages might require.
But there's no pressure on filling the keyring, I think you're mistaken on
the goals expressed here. I'm certainly interested in expanding our
community, and in recognizing the work of non-packagers as well but that
doesn't mean granting the same rights to everybody.
I'm also interested in lowering the entry barrier to some packagers,
because you definitely don't need to be DD to maintain a few simple
packages. However, since they're not necessarily aware of the bigger
picture, this might mean that they upload to a special repository and that
DD can then approve those packages to go to unstable.
It's difficult to tell if such a scheme is realistic, but then I think
it's worth experimenting at least. There are numerous ways to make it
happen. You can for example authorize the direct inclusion of a new Debian
revision in unstable but require a DD-review for a new upstream version,
or accept new upstream versions during 8 months and then have a freeze on
new upstream version, etc.
> 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.
> 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?
No. For the very same reason that forbiding DD to work on new stuff won't
lead them to fix the kernel or d-i.
> Do you think that would in turn promote a new era of 'self-selection'
> from some of those applicants?
No.
> 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?
I'm for keeping the same level of skills required to contribute
as DD.
> 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.
My response to this problem is the DPL board. The board I selected shall
represent the diversity of the project and I believe that most of what
will come out of it will be accepted by the project as a whole.
It's the only way to give back some importance to the role of DPL outside
of public representation.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: