On Sat, Mar 10, 2007 at 07:23:06PM +1030, Ron wrote: > <snip> > >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. Erm, what you're describing does not match my memory of the situation at the time. As I recall, the DAMs had a major problem with scalability - they did not have the time to do the large amount of work they saw as necessary before allowing new developers in. So the "new" NM process was started to allow other people to do more of the work, leaving DAM to do just final review. I don't remember them suggesting we should allow fewer people in. Far from it, in fact. <snip> >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? I'm curious as to how you'd propose to evaluate the judgement of those people. Team-based maintenance via alioth (or elsewhere) is a growing commodity, and that's undoubtedly a good thing. For the more important packages that are likely to hold up a release, team maintenance is a great help. To a certain extent this is self-selecting - many people are wary of taking on larger, more important packages without such help. As I've said in my platform, I'd love to see more NMs joining such teams to help out and learn more about Debian work this way. But I don't think it would be a valid or fair thing to do to keep people at that level rather than allowing them to take on their own packages as full DDs as well. >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? > >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? Or should more of the >responsibility for determining release worthy-ness be >shifted to the developers sanctioning new uploads? I'm not sure that we *have* been "increasing the number of people who've never been through a full release cycle for each new release". Do you have figures to back that up? In the end, each DD uploading packages is ultimately responsible for those packages - making sure that bugs are fixed, helping to make them releasable etc. My own experience doesn't suggest that new maintainers are necessarily any more to blame for release delays than older, more seasoned people either. >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 always be keeping or (better) raising our standards, striving for "continuous improvement"[1]. But equally we should also be better recognising a lot more of the people who help make Debian what it is - the translators, documentation authors, admins, etc. etc. All these people bring their skills and efforts to the party, yet at the moment only those people that upload packages get much recognition (be that the magical debian.org address, access to -private, voting rights, whatever). How can we fix that? I'd much rather we have that *wider* discussion than simply think about the standards of package maintainers. >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. 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... Unfortunately, as Debian has grown we do seem to have reached a point where some arguments become self-feeding. There will always be disagreements amongst developers - we all tend to have strong opinions. Where possible, consensus is wonderful. In cases where it's not possible, people who have "lost" the argument eventually have to live with that and move on. Pet ideas are all well and good, but (I hope!) we're all here to make the best possible free operating system and sometimes that means making compromises from our own original positions. Using that as a background, I belive the DPL's job within the project should therefore be to help establish the compromises where they are needed, and to encourage people to have fruitful discussions that actually lead somewhere. [1] spit! /me remembers old "quality" training courses in various jobs... :-) -- Steve McIntyre, Cambridge, UK. steve@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Attachment:
signature.asc
Description: Digital signature