Re: Who cares about NEW when there are bigger issues?
Quoting Javier Fernández-Sanguino Peña <jfs@computer.org>:
> (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]
Why the need for being that pretentious?
> 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)
I think you're right. But the diagnosis is still the same: lack of
communication. I don't think that people did not guess that ftp-masters
have other priorities than processing NEW. They just want to
be informed on what's going on. The less they are informed, the
further they feel from the project's goal.
How about explaining people that we focus on current packages and we
prefer to delay the processing of new packages for that purpose. This
would be quite acceptable, wouldn't it? At least, this would avoid
unnecessary discussions.
> > > - 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.
Ah, I thought the context was RC bugs (release showstoppers, that is).
> > > - 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.
Maybe people that are currently arguing on debian lists are fed up
with something and need to tell it? Why don't we think of the reasons
that lead people to periodically start such threads?
> > > - 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.
Before going QA, they may:
- Drop some of their packages (quality over quantity), for instance in
favour of new maintainers
- Offer co-maintaintership. Work in team is enriching and much more
interesting. I think maintainers are less territorial than they
used to be. There is still hope :-)
> > > - 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/
People hate writing docs :-P
> Again, not pointing fingers. And yes, before you ask, yes, I've contributed
> my share of documentation already.
You don't owe me any justification. I've never intended to judge you, even
if you'd practice procrastination.
> > > - 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?)
I think that the lack of communication is partly responsible for
the lack of motivation. People need to feel involved as I explained above.
I'm not pointing finger either.
> > 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:
"I want this in Debian!" means that the package is popular. A package
which is only used by its maintainers doesn't fit in this category.
> - 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)
Agreed. If the package is still used by people, it gets easily adopted
by someone else.
> - usefulness (a package which is only used by the maintainer and his close
> friends does not need to be distributed worldwide)
Definitely. Many packages fit in this category. BTW, isn't it a consequence
of the NM process?: NMs need to show their packaging skills and they usually
chose a random app that gets uploaded to unstable, even if it is rarely
used. Maybe should they rather work on existing unmaintained ones?
> 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?"
Definitely not. But what's being fair ...?
> > > - 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
Easy. But people won't search the web if you don't tell them what
they have to search for. Mentioning security audits in Debian docs would
lead people to the right direction, wouldn't it?
...
>
> 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?
You'll admit it highly depends on the size of the source code.
> > 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.
Maybe.
>
> > > 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.
I'm currently spending part of my spare time on Emacs bug
triage/fixing. You probably don't care. This doesn't deserve any
medal, but is probably useful to a bunch of users. Why would I brag
about this?
Cheers,
--
Jérôme Marant
Reply to: