Re: Proposal :)
On Mon, 1 Oct 2007, David Paleino wrote:
http://pkg-grass.alioth.debian.org/debiangis-status.html
In pkg-perl we have kinda the same thing:
http://pkg-perl.alioth.debian.org/qa/versions.html
Any source code for this available?
Well, parsing the diff.gz is one thing but I think we better relay on
the dpkg / apt-get information that is provided via a common interface.
The approach to parse the diff files sounds kind of hackish.
Well, consider that the original thing was created to be run from PHP-CLI. I've
just adapted it to web (file uploads - <br />'s instead of \n's...)
Fine, but you could access dpkg / apt-cache in both cases as well or is
there any problem?
Regarding to a general roadmap I have the following items on my notepad:
1. Pseude tasks-Files for not yet included software to enable inclusion
on the web page in the same manner as official packages
Agreed.
assigning a software name with
- Field (done by listing it in the according task file)
- URL
Parsable in debian/control (we now have Homepage: field - as discussed on
debian-devel)
Sure, but I was talking about software that has not got any debian/control
file and which is just on our todo list. For instance if you look at
http://www.debian.org/devel/debian-med/imaging
those packages at botom that marked with red. Even for the yellow ones
with inofficial packages we do not really have reliable debian/control
information (you have no idea in which strange ways Debian packages will
be builded sometimes). So for these cases we have to invent pseudo
control information if we want to build pages like this.
- WNPP bug number
- watch file
Both parsable from the debian/ directory.
As I said - it does not exist. Once a debian/ directory is created the
WNPP bug number becomes irrelevant. Also regarding the watch file I was
meaning that we could add a watch file for not yet included software to
keep some version information up to date on our todo list.
(I've written a bit of perl script which retrieves the WNPP bug number from
http://bugs.debian.org/wnpp -- not from debian/. We can use it)
Sounds interesting.
Agreed, but most things already are on the QA page (see backports, wnpp,
popcon)
Sure. I do not want to duplicate any code. We might even draw the information
directly from the QA page or use common code that is used to build this
page.
3. Quality numbers:
- ...
- Number of Mailinglists and frequency of postings on these lists
What do you mean here?
If I see a project that has 0-3 mails per month 50% issued by the main
author and 25% SPAM I would call this project dead. So it is a quality
measure that gives some information whether it is worth to spend some
time in packaging this project or let it rest in peace. Once I try to
make up my mind about a project I always have a look into the related
mailing lists.
- size of source archive and number of lines of code
We could even make a graph of the packages basing on lines of code :)
(/me really likes the idea)
me to. :)
These are information about included and not yet included pieces of software
that would be interesting to evaluate the quality of the software. All this
stuff is not really Debian-Med specific but should concern other CDDs like
Debian-Edu, Debian-Jr, Debian-GIS etc.
Sure, why not? :)
There is surely no reason against it. I was just preparing to move this
thread to the debian-custom mailing list - perhaps I'll write a summary
once we settled down this discussion.
P.S.: /me goes to study -- Laboratory Diagnostics exams on Oct, 9th. :(
Good luck
Andreas.
--
http://fam-tille.de
Reply to: