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

Re: [GSoC 2013] Yet another PTS rewrite in Django

Hello Octavi,

On Mon, 29 Apr 2013, Octavi Font wrote:
> I haven't finished the project schedule, but I wanted to check with you
> that we were on the same page feature wise. If there is any part you find
> lacking or underdeveloped, suggest away!

It's great to see that you tried to show how you intend to bring modularity
to the rewritten PTS but the modularity that you show doesn't match exactly
the modularity that we are expecting.

Basically the PTS is centralizing information:
- (source) package information in various suites (the set of suites can vary from
  distribution to distribution)
- bug tracking information
- development-related news
- useful links
- alerts of problems / stuff to do

My current idea is that the core of the PTS should offer an API that modules
can use to extend the content displayed in the PTS. There could be a way to add
a link, to add a news message, to add an entire new box, to add an alert, etc.

That way it's easy to disable some parts of the PTS that do not make sense for a
derivative for example (in the case where the derivative wants to run its own instance
of the PTS). No need to display "testing migration information" for a distro that
doesn't use a testing-like distribution. No need to enable a list of debian/ubuntu
patche for a non-debian distro. Etc.

That said, all this doesn't preclude from using multiple Django applications
to clearly separate functionalities.

Apart from that I haven't found any major problem in you current application.
Maybe it lacks some details defining the current set of functionalities found
in the mail and web part, i.e. to show tha you have a clear idea of what it

Otherwise, good work!

> I also had some concrete questions regarding the subscription management in
> the new PTS. I have thought that a minimal dashboard where users could
> subscribe / unsubscribe to packets / tags would be most helpful, but I'd
> like your input in that regard.

Yes, it's definitely wanted. We don't have a dashboard but we already have
a basic way to subscribe from the web interface:

> Regarding the SOAP API, how important is it? Shall I offer any kind of
> legacy support in the rewrite?

I believe it's ok to replace it with a REST API.

> I also have some questions regarding the hardware this PTS would be
> deployed on. Which kind of machine is it? How much ram? Also, what is the
> whole size of the rendered pages now? And how many pageviews are we talking
> about?

It's (currently) a virtual machine with 2 Gb RAM and 2 CPU at 2.8 GHz and
apache is the webserver used. We can't easily change the webserver since it's
used by other services hosted on the same machine (qa.debian.org).

hertzog@quantz:/srv/packages.qa.debian.org/www$ du -sm web
4334	web

hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130428.gz | wc -l
hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130427.gz | wc -l
hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130426.gz | wc -l
hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130425.gz | wc -l

But beware this counts all (daily) hits, not just pageviews.

To be a bit more precise:
hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130426.gz | grep -E "GET /[^ ]+.html" | wc -l
hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130426.gz | grep -E "GET /[^ ]+.rss" | wc -l
hertzog@quantz:/srv/packages.qa.debian.org/www$ zcat /var/log/apache2/packages.qa.debian.org-access.log-20130426.gz | grep -E "GET /[^ ]+.rdf" | wc -l

Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Reply to: