Re: And now for something completely different... etch!
[ Note: I was unsubscribe to -devel due to a hw problem in my current
mail-end so this quoting is suboptimal, had to use the web archives ]
Steve said:
>Ok, sure. Here are a few one-liners about various things I'm aware of
>that one person or another wants to see happen in the etch timeframe,
>together with the name of the person who has claimed responsibility:
>
Added to my list (will resubmit it when the thread settles down).
>You seem to have a rather long wishlist of your own; are these all things
>that you personally plan to work on during the etch cycle? If so, kudos!
>If not, which ones are you expecting to spend your time on, and which are
>you looking for help with?
I'm neither brilliant enough nor do I have enough spare time to work
on all of those. I pumped up the list for others to discuss and
(maybe) take over. I'm working or plan to work in:
- QA of base packages (did my share of NMUs to some already and I'm
willing to do more, if the maintainers allow me to :)
- Security audits of core and extra packages
- Improvements of checksecurity and cron for sysadmins
- Documentation improvements (and better exposure of i18n docs)
- QA of Dummy and unmaintained packages
I would like maintainers to get involved in any and all the items of
the wishlist that they feel are worth working on. The discussion in
this thread highlights many things that people believe should be
improved on (even though there might be different POVs on some
issues). I'm sad to see some important (to me) features that
nobody else thinks are worth discussing about but if they are not done
it's no big deal.
> Javier said:
>> [ Release improvements ]
>> - Prune packages from release based on popularity, packages which are not
>> used by anyone should not go in! (not enough peer review, probably
>> not audited, bug ridden with bugs, including security making security
>> handling a nightmare)
>
>It is, after all, quite difficult to determine that a package is not used by
>*anyone*. You can use popcon to give you prospective candidates, but popcon
>doesn't prove the package is unused (and, well, a simple statement from the
>maintainer is counterevidence).
>
>That doesn't mean I think you're using the wrong metric; I'm just noting
>that the payoff for looking for unused packages tends to be very low
>:)
When doing automatic source code security auditing of some basic stuff
(/tmp races) early this year I've found an important correlation
between the popcon value and whether ASAT (my "Advanced Security Audit
Tool" (TM) [1]) had found a real security bug or it was just a false
positive. The lower the popcon value, the higher the chance of it
being a real security bug.
In any case, popcon is currently, IMHO, a better metric to detect low
quality stuff than bug counts since over-used packages (with,
consequently, have higher popularity values) attrack far more bugs
than packages that are only used by 1 person (its maintainer). Maybe
considering also the frequency of uploads to the archive or the time
of the last upload would help in detecting under-maintained stuff. I'll
let the QA team decide on that :-)
Regards
Javier
[1] Actually it was something like:
for each package in the distribution;
unpack in {package_dir}
run find {package_dir} -xdev -type f 2>/dev/null |xargs grep -ir "/tmp" |
grep -v ^/usr/share/doc
:-)
Reply to: