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

Re: task & skills



On Sat, Dec 02, 2000 at 06:37:30PM +0100, Gergely Risko wrote:
> Hello!
> 
> 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

4 bytes (CRLF x 2) for clarity. 

>  
> > 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.

My point was not that you errors (i think using debhelper is a worse bug
btw - dpkg-statoverride is what you should be using).

> > 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

Fine teach them. Don't be surprised if they get annoyed and that isn't
part of your "job" description.

> 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.

Ah. So we should only accept maintainers who make it easy for people in
Hungary to keep up to date?

Please add that to the list of new-maintainer requirements.

> > 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.

There is nothing like actually getting your hands dirty and "just doing it"
to make (or break) a maintainer. Braden "overfiend" Robinson is a good
example of someone who just picked up the X pieces and ran with it.

I suspect if he had to suffer tutelage he may not have bothered.

> 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!

If what you are doing is teaching the way you describe ( and I'll say
upfront it is taking me some effort to parse your english -- thanks for
perserving in a non-native tounge ) then perhaps you being too strict?

> 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.

Okay, thanks. Once the Linux conference I've been organising is over
I'll pickup some more.

> 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!

"really done" is a pretty nebulous definition imo. The items in the
checklist <URL: http://www.debian.org/devel/join/nm-step4> are far
more concrete.

> > 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.

So perhaps spending time with an applicant who, it is likely, will
upload a buggy package isn't worthwhile. Or perhaps not as much
time.

> > 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.
> no comment.
> 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.

Once again, 4 bytes (CRLF x 2) for clarity and understanding.

Since you aren't a native english speaker i want to spend my
time reading your comments - rather than deciphering where they
start and stop.

> 
> PS: I was a quite nervous, this is the main reason for the criticism.

Um, okay.

Anand

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



Reply to: