(Note: In order for this thread to prove useful I'm going to adhere to aj's ObBug: rule [0]. This will also probably limit my answers somewhat and prevent me from answering every post] On Tue, Mar 08, 2005 at 12:05:32PM +0100, Jérôme Marant wrote: > What's the purpose of NEW then? Why are packages allowed in NEW > while preparing the release if they're not going to be processed? I didn't say that NEW doesn't have a purpose. I said that _right_now_ people shouldn't be so much worried about it. But that's just me. Of course, there are corner cases: libX that replaces libY and needs to come in to fix bug Z, but most of the NEW packages are just that .... NEW. That includes hot-babe and other popular software like mplayer, php5, gcc4, postgresql8, horde3 but it also includes software which probably is in alpha/beta state (version numbering <1) > > - Too many open bugs for too much time in base packages > > Which are not the easiest packages to fix, are they? You may > be skill enough to fix GCC or GLIBC, but I'd bet not everyone is. Base package also have trivial bugs (even translation related) which are open for ages. Check the BTS. I've done my share of NMUs to base packages and I'm not a GCC guru. > > - Too many inactive maintainers that just use their XXX@debian.org e-mail > > address, talk in lists but don't contribute code or documents or what not. > > I'd call this freedom, unfortunately. I'd call this "Debian is just like an ISP for some people". Sorry, not contributing actively when that's what you signed for is not freedom. And, answering another answer to this, no, if you are only contributing ideas in the mailing list you are not a Debian maintainer, you are just somebody voicing his ideas and you dont need a debian.org mail address for that. > > - Too few people actively doing QA of _others_ packages > > There are some people spending their spare time in properly > maintaining their own packages. Why accusing them of not doing > others' job? Furthermore, I think that when people are able > to send patches, they do so. Debian needs a big and active QA team. I'm not pointing fingers. I'm just stating that QA is not as big as it should be. Maybe maintainers should reconsider what are they working in and should involve with QA activities instead. > > - Too few documentation (oriented towards our end-users) > > Such as? User (not admin-) oriented documentation (an updated Progeny user's guide for sarge, anyone?). The FAQ is not up-to-date, Release notes are rather untested (corner cases are not covered in the documentation such as #278495). Compare http://www.debian.org/doc/ with http://www.redhat.com/docs/manuals/enterprise/ Again, not pointing fingers. And yes, before you ask, yes, I've contributed my share of documentation already. > > - Too many people pushing in different directions without contributing to > > the common goal: release > > How would you motivate people? There are people who have already > frozen their own packages a long time ago, trying for instance not > to upload a new upstream release. I'm not sure I know how to properly motivate people, otherwise I would have (maybe) taken different steps (DPL elections anyone?) > The best way to motivate people is to release more often and to > have stricter release plans. I concur with this. > > - Too many packages in our release, many of which only a few use > > Easy to fix: decrease the number of release-candidate packages, based > on popcon for instance. Well, your "easy to fix" will find other's people "I want this in Debian!". Whomever's louder currently wins. There are no procedures for removing stuff that nobody uses from our distributions. Again, a task some QA people have been doing to their best of their abilities and have removed buggy packages after proding their maintainers but we don't have an in-place semi-automatic procedure to remove packages based on things like: - buggyness (packages with many bugs which have seen no activity in a long time, packages with bugs tagged as patch that are not applied, optional/extra packages with RC bugs for a long time, etc.) - inactivity (a package which is 2 years old probably does not conform to our latest Standards) - usefulness (a package which is only used by the maintainer and his close friends does not need to be distributed worldwide) Again, I'm not pointing fingers, I've probably have packages that fall in some (of all) of the above at some point. > Further: do not accept every package to enter Debian... Should be done, but if ftp-maintainers take this decissions they get bashed on the basis of them preventing "freedom". And we're back again to the pointless hot-babe discussion which drills to "should Debian be a software repository of every free software project written on earth, regardless of its state and value?" > > - Too many security bugs in too many packages which nobody has audited > > before release > > Add to documentation pointers to secure programming and HOWTO audit > code. Not everyone is "security-sensitive". No need to when there's Google. I bet you can plug those three words "secure programming howto" and go to, guess what: "Secure Programming for Linux and Unix HOWTO" by David Wheeler, excellent book BTW (http://www.dwheeler.com/secure-programs/) In any case, may security bugs are just related to careless programming and a maintainer is _expected_ to know what his stuff is programmed in. Auditing source code is not high-tech stuff it _is_ time-consuming however. If you think auditing for security issues is complex just take a look at http://www.debian.org/security/audit/bugs and http://www.debian.org/security/audit/advisories That's the result of four people working on their spare time (Steve Kemp, Ulf Härnhammar, Jaguar and myself). If you are curious as to many of the bugs _I_ have reported, they are just related to running 'grep -r "/tmp/" .' first on my local system and then on all the source packages in Debian and reviewing the results. Obviously something any maintainer with a few minutes of spare time could do by himself for the packages he works on, don't you think? > Unless you want to "fire" people for not doing their job, there is not > much to say about this. I don't want to fire people, I'm just saying that maybe we should determine what is "crap" and get rid of it as this is bogging us down in many fronts. > > PS: Fixed and uploaded #279483 and #292176 and #296311 before > > mailing this, BTW. Just to put my hands where my mouth is. > > Bragging. Yep, but that's 2 RC bugs less for release and I invested my share of time in getting those bragging rights. Bet if everyone did this there would be less issues to take care of. Regards Javier ObBug: #298072, #295554 ObReviewed: #298473, #297912, #297283, #298114 [0] http://lists.debian.org/debian-devel/2004/10/msg01434.html
Attachment:
signature.asc
Description: Digital signature