Re: task & skills
On Sun, Dec 03, 2000 at 04:04:15AM +1100, Anand Kumria wrote:
> [ Note I put in extra lines to make clear what you responded to, please
> put in an extra line ]
ok, one line for band witch
one line for archive space
one line for mirrors
> On Thu, Nov 30, 2000 at 07:47:31PM +0100, Gergely Risko wrote:
> You know, I would have failed the new-maintainer process then.
You wouldn't fail, you only had to learn packaging, and you wouldn't
upload so many packages with lintian errors.
> 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>
About my two lintian warnings, if you saw my packages, you know that these
warnings are bug in lintian. One about suid game. Now we the debhelper
uses postinst to make a game setgid, not in the file rights itself.
> Even reasonably experienced maintainers do this.
I don't know about others, but I will teach my applicant how to package
up a program. And I ask them to fix all of the bugs, after that them
t&s will be ok. Until now only two of them can do it, but they will be
good maintainers, I hope James will aprove Vries as fast as he can, and
he can start to upload him lintian free, good, easy to install packages.
> So? That is why we have a bug tracking system and don't insist on
> everyone being perfect.
Yes, we say, we can got bugs, because erverybody can view BTS and upload
from the net. But here (Hungary) the upgrade to r1 on modem line costs
about half an hour of work (so an avarage worker, programmer, etc need to
work half an hour for the update). I thikn we need as many pckjages
as we can do without SO MANY BUGS in stable. Some buig companies haven't
got net connection, or they net connection not so fast.
And Hungary is not the worst place to live.
> 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.
I said only, that I will teach my applicants to be the best maintainer,
in this way the approve time will be longer, but the bug fixing time woll
be less, because we will got fewer bugs with better new maintainers.
In this way our numbvers will be increased.
But I decided now, that I won't accept more applicants, because they
think that I'm the most strict AM, and I do it because I'm evil, or I don't
want to approve them. Other AMs approving most of the applicants in one day!
I won't declare me as an evil AM, I will go back to adopting, and
debianize new packages, and leave the work of the new applicants to you.
But an ask to James, please only approve applicants, who got them
tasks and skills test really done, now when I adopted one or two
packages, I saw a lot of bugs (eg build-depends) in the pacakges which
are in thje archive. I don't want to see more, please!
> 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.
ok, I can't demostrate it, because the developers are also upload
buggy packages, and this slows down the way of good packages to archive.
I only say that my 38 applicant will be thought to be a good
maintainer, and after that I won't accept new applicants.
> 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.
one line for archive
one line for mirrors
one line for applicants with bad poackages
this mail will waste less bandwich than the unless incoming mirroring,
with bad packages.
one line for incoming mirrors.
PS: I was a quite nervous, this is the main reason for the criticism.