Re: Improving the DAM-queue?
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 <firstname.lastname@example.org> [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 . 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.
 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.
Imagine a large red swirl here.