On Sat, Dec 02, 2000 at 09:08:42PM +0100, Lenart Janos wrote: Ok, I'm answering just to state my views on the prolly most common pitfalls where a nm canditate like me can fall, and to write about this whole thread (just a general view): > Hello! > > [ Well, I don't want to quote from Gergo's or Kumira's mail, I really > hope that everyone read *and* remember them. ] > > I don't agree with Kumira's mail. > > I think our goal is to create a good, trustable OS, that one includes > as much valuable program as much we can debianize. Currently Debian is > stands for these. Debian is on the top because it's organised very > well, it has high standards, DSC and others. Quality must be much > more important than quanity. Am I right?! > Yes, you're right, but even that really depends... having a top-notch 1,5 year old without recent sotware will not be very attractive even if it is extremely stable; on the other hand having, say, an experimental release of a compiler packaged (just a wild idea that came to mind) and given as default and having a lot of packages that have wrong depends, conflicts, etc (the kind of things that makes dpkg/dselect/apt crazy) is also very bad... in a dream world Debian should have both; in the real world Debian should be the one *close* to having both. > Our philosophy is 'help the applicants'. Approving them anyway (in > the hope they won't screw up the user's system) is not good for anyone > Helping the applicants takes lot's of time from the applicants who can > read those manuals before submitting their apply query. I don't think > the NM process should be a 'school', and I don't know why AMs have to > spend time for applicants who don't read manuals, just ask. They should > be rejected after one or two questions. For example, that's trivial > that some of them can't even use gpg, don't know about lintian, etc. > Everyhing is written down clearly. Ummm.... not so clearly actually (well, it becomes clearer after a while)... e.g. the first doc a nm reads is the newmaint manual; well, I red it, and since it concernes the DH_COMPAT=1 level several things are quite different (say, /tmp file doesn't exist, some dedhelper things are diff, etc); this is an example... the documentation is good and extensive (between manuals and man pages), but one must understand that making a deb is not as simple as running dh_make... only by working, making errors, reading, correcting can one begin to produce good packages; I've red 4 manuals and the things I remember more clearly were the ones were I made a mistake. > > I have an idea: The applicant should must fill a form before apply. > This form would contain questions like: > " What is lintian? > A) LINux Teachers International AssociatioN > B) lintian is Debian's very old document > C) lintian is package checker" > > and, if he can answare 5/5 questions only then he can apply. Of course, > there would be only questions that can be checked by a script. With > this we can avoid web-surfers wasting AMs time. > > One other thing: > BTS. Yes, BTS is exists, but that is for the bugs we don't know before > upload (it should be for them!). Applicants who can't run lintian > should be rejected without further questions or discussions. > Well, I run lintian and my package is lintian-free... is it good enough? I don't know, because there are several things that lintian doesn't (and can't check).. I understand you're point of view and I agree with it, t&s can't be reduced to sending a package totally made by the scripts (no copyright, Debian.README empty, etc) - well, it can, but then it could just as well be abolished. In the long run I believe that applicants should be admited after producing an error-free package, even if that requires mails between the AM and the NM explaining why. Still, the fact remains: there isn't a standard checklist for t&s, and that leaves to the AM the judgement, always personal, of the ability of the nm. Just my 2 cents, fsm -- Frederico S. Muñoz GNU http://www.gnu.org fsmunoz@sdf.lonestar.org Debian http://www.debian.org http://sdf.lonestar.org - SDF Public Access Unix Systems
Attachment:
pgphiwwrhFJq3.pgp
Description: PGP signature