[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: task & skills

[ Note I put in extra lines to make clear what you responded to, please
  put in an extra line ]

On Thu, Nov 30, 2000 at 07:47:31PM +0100, Gergely Risko wrote:
> Hello!
> On Fri, Dec 01, 2000 at 01:57:05AM +1100, Anand Kumria wrote:
> > Yes, this upsets me. (Why the rest of the AMs aren't up in arms
> > is a worry).
> > 
> > You seem to want to continually throw extra hurdles in the way of
> > potential maintainers. We are not even close to packaging all
> > the new and interesting free software yet.
> I think this extra hurdles are needed, now I've got 39 applicants,
> and I see that they can be so silly. Some of them leave in .ex files,
> put an undocumented.1 to debian dir (!! I ask is the applicant ever
> read the docs? the dh_undocumented is in the example!). Some of them

You know, I would have failed the new-maintainer process then.

Packages have bugs. People make mistakes. I make many, see my
entry in <URL: http://lintian.debian.org/reports/mAnand_Kumria.html>
Lintian, or James's <URL: http://lintian.debian.org/reports/mJames_Troup.html>
or your own. <URL: http://lintian.debian.org/reports/mGergely_Risko.html>

> can't make an apt-getable directory. If you don't ask you won't know

I bet a *lot* of developers aren't aware of how to do it. But your
next sentence (well the start of) is important.

"if you don't ask ..."

> about this fails of them, and they would upload badly signed, useless
> big and other buggy packages which will do work for the ftp-masters.

Even reasonably experienced maintainers do this. 

> And some of the bugs wouldn't be found by the scripts, so it will
> be in woody, and it will be on CDs. If many bugs will appear on CDs,

So? That is why we have a bug tracking system and don't insist on
everyone being perfect. I fail to see the correlation between
new maintainers and buggy packages. Feel free to point *any* data
you have on this.

With over a 100 new maintainers I'd have thought we would have
enough to determine buggy new maintainers tend to be.

> then users will thought that debian starts to tend to be as buggy
> as other distributions. I think that good tests are needed for 
> this procedures, and I think also that this is as important as p&p.

We are talking about prospective maintainers, right?

These are people who care enough about Debian to actually bother to
apply to be a maintainer so they can help make the distribution
better for themselves (and hopefully in addition others).

And you are supporting the point of view that rejecting them will
increase our numbers? Sorry I don't follow the logic.

> > Sourceforge containers, I hear, about 30000 projects. Debian has
> > only 10% packaged [0]. We have a long way to go.
> Yes, but we need high-quality packages. The packages in the 90% need
> to be as good as the packages in the 10%.

Please demonstrate a correlation between new maintainer-ness and
buggy packages. If there is one I could probably accept that
more checking of the tasks and skills would need to be done.

> > The new maintainer has been slow for a long time (and it still is
> > backlogged -- unfortunately the conference is a lot more work than
> > I imagined) I don't think we need to slow it down further.
> But I think if we don't slow them now than the full debian will slow
> down at other places. For example the incoming queue with flooded
> bad packages.

I'm sure the ftp-maintainers are rather busy with converting Debian
to using pools - but that (should) allow a lot more automation and
make things less time-consuming in the long run (James, care to 
speak up if this isn't the case) so I don't really think this is
a valid concern.


Linux.Conf.Au			--		http://linux.conf.au/
17th - 20th January, 		--		Alan Cox, David Miller,
Sydney, Australia 		--		Tridge, maddog and you?

Reply to: