Re: Who cares about NEW when there are bigger issues? (was Re: Is NEW processing on hold? (was: Question for candidate Towns))
Quoting Javier Fernández-Sanguino Peña <jfs@computer.org>:
> On Tue, Mar 08, 2005 at 07:52:23AM +0100, Marc Haber wrote:
> >
> > IMO, this actually _proves_ the case that ftpmaster is one of the
> > biggest problems that Debian has at the moment, now that the DAM
> > problem has been solved elegantly and efficiently.
>
> Wrong, the BIGGEST problem is that we have so many people whining about NEW
> and about other "problems" when at the same time the RC bug count does not
> lower enough for us to make a release. Other _bigger_ problems:
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?
> - Maintainers do not do enough do QA in their _own_ packages
Probably. I still stand that allowing new upstream releases
in unstable while trying to release is a mistake.
Not doing would help concentrating of fixin
> - 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.
> - 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.
> - 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.
> - Too few documentation (oriented towards our end-users)
Such as?
> - 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.
The best way to motivate people is to release more often and to
have stricter release plans.
> - 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.
Further: do not accept every package to enter Debian...
> - 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".
> - Too many careless coding in too many package
> - Too many undocumented binaries
>
> I _do_ have packages waiting in the NEW queue. Know what? I really don't
> care if it gets 10 days or 40 days or 2 months to process them. I actually
> _do_ care that we don't release because maintainers are furiously sending
> e-mails to -devel and others lists instead of sitting down, finding and
> fixing RC bugs.
Unless you want to "fire" people for not doing their job, there is not
much to say about this.
> Regards
>
> Javier
>
> PS: Fixed and uploaded #279483 and #292176 and #296311 before
> mailing this, BTW. Just to put my hands where my mouth is.
Bragging.
--
Jérôme Marant
Reply to: