Re: Guidance required for GSoC project PTS rewrite in Django
thank you Paul for having shared your ideas. They are all very
interesting in some ways but most are probably out of scope
for the GSOC project that I and Stefano are mentoring (I'm saying
this just to avoid confusion in the students heads).
On Thu, 25 Apr 2013, Paul Wise wrote:
> The Debian archive presently only exports an apt archive and sends
> events out as emails, mainly aimed at humans not machines. This year
> there is a planned GSoC project to change this and make dak spit out
> AMPQ events using fedmsg, enabling Debian and other services to get
> realtime updates about package uploads etc.
Interesting indeed, but it's impossible to plan a GSOC based on something
that's going to be developed in parallel.
> Then there is UDD (Universal Debian Database), which is a project to
> import all sources of data about Debian into an SQL database
> (currently PostgreSQL). It has a lot of data but the data in UDD is
> different to the PTS (some extra, some missing).
> The PTS was created before UDD. It is pulls data in from a variety of
> sources (update_incoming.sh), converts that to xml (excuses_to_xml.py
> other_to_xml.py sources_to_xml.py) and converts that to HTML
> (generate_html.sh) using XSLT. Some data is also pushed to it via
> email (the news mainly).
Using UDD as one possible source of data is certainly desirable
in the planned rewrite. But expanding the scope of UDD is not really
planned (unless we have UDD maintainers who are very reactive).
I'm not expecting the students to contribute code to UDD.
> Realtime updates so that developers can get correct information. The
> current situation is suboptimal.
Agreed. We should at least be prepared for it.
> Static HTML since it is faster to load and means we can distribute the
> content to multiple hosts in case of downtime (not done yet).
Static HTML is not a requirement that I plan to impose. At least
not down to the pre-generation of all HTML pages.
On the contrary, I see the PTS evolving in something much more interactive
and dynamic. As an example of future extension (outside of the scope of
this GSOC), it would be nice if people could fill missing debtags directly
in the PTS and then package maintainers + DD could approve them. Or if
people could fill-in upstream metadata (upstream VCS, BTS, etc.) that we
don't want to store in debian/control currently.
> doesn't need logins/admins/etc. No need for passwords since we don't
> have them currently. Passwords are also a less than ideal
> authentication mechanism, if we need authentication at all we should
> use something better like OpenGPG keys or client-side SSL
It's still interesting to authenticate people so that we can subscribe
them to packages more easily (for a better integration with the mail
And later to handle other kind of operations (as suggested above).
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook: