On Sat, Oct 14, 2006 at 02:37:14PM -0700, Steve Langasek wrote: > On Sat, Oct 14, 2006 at 11:53:27AM +0000, Bill Allombert wrote: > > On Wed, Oct 11, 2006 at 10:14:39AM +0200, martin f krafft wrote: > > > also sprach Bastian Venthur <[EMAIL PROTECTED]> [2006.10.11.1002 +0200]: > > > > This is quite frustrating, since most of the applicants are surely > > > > doing already the normal work every Developer has to do, but are > > > > not able to upload or participate on current votes. > > > > I agree that this might well be frustrating. However, I also oppose > > > to any measure to increase the new queue throughput until we figured > > > out how to also get *rid* of DDs. Our project is too large; we can't > > > just keep growing. > > > I absolutly disagree. Every Debian contributor doing work we depend on > > for the continued activity of Debian should be a DD. > > > We have nearly the same number of registered developers than at woody > > time however we have expanded operation by about 250%. We need more > > developers to better spread the load. > > Rather than kicking out those developers who have added to the bloat of the > archive without taking responsibility for the long-term consequences of the > packages they've added? :) > > You appear to believe that adding people to the project will improve the > ratio of developers to packages. I do not; I expect it will cause the > number of packages to increase in proportion to the increase in developers, > because people choose to become developers to scratch *their own* itches > and those will frequently be different than the itches of those who came > before them and left behind orphaned packages.
Given the current exponential package growth, I don't think adding will more developers more quickly will increase it. It will reduce the number of sponsored upload but that is rather a good thing. What you describe is another Debian problem: The cardinal rule in Debian is "Do not bother other developers". From that point, adding new packages is safe, trying to join a team is not, and there is no incentive to do it. Rather there are too much example of "Do not bother us, we will eventually sort it out". There are too much artificial barrier for new member [1]. What we need is a better "New <team> Member Process". In that regard, the Release team process has been much much better than other team despite the long delay between the initial application and the first contact. (Without that delay I would have made different arrangement for my schedule) The fact that the NM process is packaging-centric does not help but is merely a consequence of the above paragraph. [1] The same happen for unmaintained packages: the hurdle for taking them over is so high most maintainers do not bother. Consider that I have hijacked most of my current packages so I know something about that. There are "maintainers" that never made a single upload of the package, the last upload being 3 years old, but will not even let you do an NMU to fix trivial-to-fix but painful bugs. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
