| Javier Fernández-Sanguino Peña 2005-03-08, 5:52 pm |
| (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)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?"
>
> 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.
>
> 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-deve...0/msg01434.html
|