On Wed, Mar 20, 2013 at 04:28:14PM +0800, Paul Wise wrote: > [Please keep the bug in CC]
Yep. I noticed my mistake in last mail and bounced it right after sending to the bug > On Wed, Mar 20, 2013 at 12:55 AM, Andreas Tille wrote: > > > If it comes to Blends topic I am an UDD folk. ;-) > > You should simply specify what data you need and I will go for it. > > So, a machine readable file (YAML/JSON/deb822/etc, your choice), > something like this: > > Blend: Debian Med > Task: Biology > Task-name: med-bio > URL: http://debian-med.alioth.debian.org/tasks/bio > Packages: abacas acedb-other .... > > Blend: Debian Med > Task: Biology development > Task-name: med-bio-dev > URL: http://debian-med.alioth.debian.org/tasks/bio-dev > Packages: bioperl bioperl-run 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 ( -- fieldname type, -- example value blend TEXT, -- 'debian-med' (== the source package name) blendname TEXT, -- 'Debian Med' (== human readable name) projecturl TEXT, -- 'http://debian-med.alioth.debian.org/' tasksprefix TEXT, -- 'med' PRIMARY KEY (blend) ); CREATE TABLE blends_tasks ( -- fieldname type, -- example value blend TEXT REFERENCES blends_metadata, task TEXT, -- 'bio' PRIMARY KEY (blend, task) ); CREATE TABLE blends_packages ( -- fieldname type, -- example_value blend TEXT REFERENCES blends_metadata, task TEXT REFERENCES blends_tasks, package TEXT, -- 'gromacs' PRIMARY KEY (blend, task, package) ) These tables could be filled from configuration files in git://git.debian.org/git/blends/website.git in dir webtools/webconf as well as from tasks files in SVN. When thinking twice it might be worth considering to drop the webconf stuff in favour of putting the information in question right into the source package metainformation. But this could be decided / adapted later. >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? > > I'm sorry I can not really parse what you want to tell me with this. > > I'll try again. The PTS is primarily source package based but the > blends infrastructure is binary package based. The PTS will want to > link to the blends infrastructure, using per-package anchors. The > anchors provided by the blends infrastructure are based on binary > package names rather than source package names. Here is an example > based on the logol source package: > > <a href="http://debian-med.alioth.debian.org/tasks/bio#logol-bin"; > title="Debian Med Biology packages">med-bio</a> > <a href="http://blends.alioth.debian.org/";>blend</a> > > It would be much better if the PTS could link directly to a source > package anchor instead, especially since blends can sometimes depend > on multiple binary packages from one source package. Unfortunately it > isn't yet possible to do this: > > <a href="http://debian-med.alioth.debian.org/tasks/bio#logol"; > title="Debian Med Biology packages">med-bio</a> > <a href="http://blends.alioth.debian.org/";>blend</a> Ahhh, OK. Adding an additional anchor mentioning the source should be no problem in principle (at least not when the planed changes will be implemented - I'll issue a GSoC proposal about this). However, there is always a number of binary packages from one single source package inside a single task - this would result in duplicated source package anchors which IMHO is not a really good idea (I guess browsers are defaulting to the first anchor - but finally something is happening you really want to 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. > Alternatively we can drop the anchor, since I guess folks clicking on > blends links are looking for other related packages rather than the > package itself. IMHO this would be the better solution because it resolves the conflict above. > Thats a separate issue to what you pointed out with gromacs, the > gromacs issue can be solved like this: > > <a href="http://blends.alioth.debian.org/debichem/tasks/molmech#gromacs"; > title="DebiChem Molecular mechanics packages">debichem-molmech</a>, > <a href="http://debian-med.alioth.debian.org/tasks/bio#gromacs"; > title="Debian Med Biology packages">med-bio</a> > <a href="http://blends.alioth.debian.org/";>blends</a> > > And if the length of the blends list gets too long we can do it like this: > > <a href="http://blends.alioth.debian.org/";>blends</a> > (<a href="http://blends.alioth.debian.org/debichem/tasks/molmech#gromacs"; > title="DebiChem Molecular mechanics packages">1</a>, > <a href="http://debian-med.alioth.debian.org/tasks/bio#gromacs"; > title="Debian Med Biology packages">2</a>, > <a href="http://debian-med.alioth.debian.org/tasks/cloud#gromacs"; > title="Debian Med Cloud packages">3</a>) OK, that's fine for me. I will not question PTS development decisions. In any case I'd applause the intention to make Blends more visible. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
