[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal :)



On Mon, 1 Oct 2007, David Paleino wrote:

To work with the Debian BTS, we could use its SOAP interface [1], that shouldn't
be too much difficult.

Any work on this is greatly apreciated.

About the dependency thing you're talking about, we could parse the *.changes,
or even Packages.gz to get the packages in the repository... or even parse what
http://package.debian.org/<package> outputs for each package. We should write a
roadmap, or kinda.

Well, I tried to have a readmap in my CDD paper which is kind of very outdated
but recently reached the top of my todo list because I made some heavy changes
to the cdd-dev code that have to be reflected in the doc.  You must know that
I consider those things not only as Debian-Med business because in principle
all other Custom Debian Distributions have the same requirements which means
we definitely should join forces and use the same techniques.

The only thing that is written down for the moment is

   http://people.debian.org/~tille/cdd/ch-todo.en.html#s-visibility

and here the pargraph 8.2.1 and 8.2.2.  In addition to this I'm currently
thinking about how to reasonable generalise the interesting page at

   http://pkg-grass.alioth.debian.org/debiangis-status.html

A parapgraph 8.2.3 about this will be written soon.

(once I made a simple PHP script which parsed a .diff file (*.diff.gz
gunzipped) and output various info -- I'm uploading it to [2] -- the diff file
is a sample diff from one of my packages). We can use this script to take
information about our packages ;)

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.

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

   assigning a software name with

   - Field (done by listing it in the according task file)
   - URL
   - WNPP bug number
   - watch file

2. http://qa.debian.org/developer.php - like page

   obtain everything the packages overview is listing plus

   - backports
   - WNPP bug
   - Popcon
   - "watch"
   - lintian messages
   - debtags

3. Quality numbers:
   - number of users (obtained by popcon)
   - version number
   - date of last version
   - Number of Mailinglists and frequency of postings on these lists
   - size of source archive and number of lines of code
   - upstream author and does he answer "pings"

4. Technical description:
   - Programming language
   - Used database

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.


I got a [RKI-Spam-Verdacht] tag on the reply I received. Not on this, though.

Which means RKI = my institute; Spam = Spam :); Verdacht = suspicion.
I think you should ignore this - no idea why this genearl filter catched
it - my own fine grained one did not.

Kind regards

        Andreas.

--
http://fam-tille.de



Reply to: