[Blends SoC] Re: SoC project, enhanced blend webtools
- To: Diego Escalante Urrelo <email@example.com>
- Cc: Custom Debian Distributions <firstname.lastname@example.org>
- Subject: [Blends SoC] Re: SoC project, enhanced blend webtools
- From: Andreas Tille <email@example.com>
- Date: Fri, 13 Mar 2009 09:15:49 +0100 (CET)
- Message-id: <alpine.DEB.2.00.0903130853110.14916@wr-linux02>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com>
I hope you don't mind if I quote you via the list but I just want my
response kept on a better place than just private inboxes ...
On Thu, 12 Mar 2009, Diego Escalante Urrelo wrote:
I'm interested in the SoC project listed on Debian's wiki about
enhancing the blend webtools integrating them to UDD and debtags.
I was wondering if you could give me more details about it to .
I understood that it's basically a matter of switching to use UDD as
the only data source and come up with more and nicer ways of
filtering/showing information, perhaps creating some new reports or
tools. Am I right?
Many thanks for your interest. The task is basically to enhance
There is a python module blendstasktools.py which is parsing Packages.gz,
Sources.gz and Translations.gz files to gather the needed information to
build the tasks and bugs pages. This has several constraints because
it takes quite a time to parse all needed Packages files (for all dists
and archs in principle, currently it is done only for sid and i386).
I realised that this would be a very simple task if using UDD - just a
simple select and viola all information is there.
Currently this is not possible with DDTP translation files but I'm currently
busy to inject this information into UDD. The missing piece is that the
translation files are lacking the information about the version of the
package where the translation belongs to. I will meet Michael Bramer this
weekend who promissed to solve this and than in principle a DDTP UDD gatherer
This could lead to a 1:1 replacement of the current tasks files.
The next plan is to go on with the following steps:
1. Parse new queue and inject the information we need for the tasks
files into UDD (I wrote 70% of the code which is needed and think
I will finish this until end of March).
This would enable adding a section of the packages in NEW
2. Find a reasonable way to move the content of Blends tasks files
This would add a further layer of abstraction and makes creation
of the tasks and bugs pages even more simple.
3. Inter-Blend relations For instance if science-biology depends
from med-bio resolve the dependencies of med-bio and lilst these
on the science-biology tasks page instead of just med-bio etc.
4. Handling dependencies of libraries save against version changes.
If a library undergoes a version change it is currently not found
by the Blends tools any more. Similarly but perhaps even harder
to handle are packages with explicite version numbers (octave,
5. If the tasks file contains information about a prospective package
(not yet official Debian package but a DD is working in Vcs on
packaging stuff) this info should be parsed and used for the tasks
pages (and perhaps the Blends UDD information updated accordingly)
6. Implementing Popcon stats (just in UDD) on the tasks pages.
7. Adding information of screenshots.debian.net to tasks pages -
this information is missing in UDD but it could probably easily
8. Implementing a link checker to make sure all information on the
tasks pages is correct. It might be reasonable to check any
link in UDD and let tasks pages simply profit from the verified
9. Adding some usage sugar to the tasks pages
10. Use UDD information to build the debian/control file of the
source package of a blend.
11. Whatever idea you might have in addition.
This is basically my todo list which would take me quite long for
time constraints. If this sounds reasonable to you or somebody else
I would be happy to mentor work on this.