Re: Bug#703402: PTS: link to the blends website for packages involved in blends
On Thu, Mar 21, 2013 at 12:05 AM, Andreas Tille wrote:
> Well, machine readable file is one thing. At first we need to define
> the SQL table layout. Currently the philosophy in UDD is to have the
> tables not normalised but I think it makes sense to normalise to some
> extend into three tables because it simplifies things we intend to do:
>
> CREATE TABLE blends_metadata (
...
> CREATE TABLE blends_tasks (
...
> CREATE TABLE blends_packages (
...
I'm not an expert in SQL, but those look good to me.
> From the table layout above it is a simple task to create YAML,JSON
> which I consider rather *your* choice - I even wonder if there is any
> need for an intermediate format. Isn't PTS not created from UDD
> queries?
The PTS isn't created from UDD queries, but I think/guess/hope the
planned rewrite would be:
http://wiki.debian.org/SummerOfCode2013/Projects#PTS_rewrite_in_Django
So for now we need an intermediate data format. JSON or YAML is fine,
both of those are currently parsed by the PTS, munged, turned into XML
and then rendered using XSLT. I'd recommend a list of tasks with their
names and lists of packages.
> prevent). So this approach is a bit hackish because there is a reason
> why tasks are binary package centric (== user oriented) and PTS is
> source centric (== developer oriented). I guess this mix of target
> groups leads to the technical problem we are facing.
Agreed.
> IMHO this would be the better solution because it resolves the conflict
> above.
Ok, lets do that.
> OK, that's fine for me. I will not question PTS development decisions.
Please do question PTS decisions when appropriate, the PTS should
serve the needs of the Debian packaging community and if it isn't
doing that, we should fix it.
> In any case I'd applause the intention to make Blends more visible.
There are more ways to do that, I can think of at least two, will
bring those up in a new thread.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: