Re: [GSoC 2013] PTS rewrite in Django

I've updated my application in response to your suggestions and concerns. The changes are detailed below.
On Mon, Apr 29, 2013 at 1:12 PM, Raphael Hertzog <hertzog@debian.org> wrote:

Hi,

On Mon, 29 Apr 2013, Apoorv Upreti wrote:
> I've put up my application on the wiki:
> http://wiki.debian.org/SummerOfCode2013/StudentApplications/ApoorvUpreti
> Any comments, criticisms or suggestions would be most helpful.

It looks like a solid proposal, good work!

Good to know! :)

A few comments:

- “(Optional, if time permits) Creating a portal where subscribers can
register and add/delete subscriptions”

=> to me this part is not optional at all, we have already have a
limited web subscription form and we need to keep that feature,
and rewriting it in a way that makes sense (i.e. using django's auth
mechanism to allow direct subscriptions without going through an email
challenge)

Alright, I've updated my application to reflect this. I did notice that currently subscribing to a package via the web interface just shoots off an email to the email interface. Direct subscriptions would be better.

- if you really want to deploy in september, you have to build confidence
in the new infrastructure by making it available to users much sooner,
so that they can use it while you're still working on it. A weekly
iteration seems a good idea (we can arrange something for the hosting).
Thus you need to consider deployment strategies much earlier. (And I
would suggest to provide a Debian package to make it easy to deploy the
code.)

I could work on a deployment strategy during the community bonding period. In fact, I could set up an empty django project, create a Git/SVN repository on the server and on bitbucket, set up other tools for easy deployment like fabric and virtualenv, set up the stack on the server and by the end of the community bonding period, we could deploy this empty project with maybe a model and a couple of views to ensure that the deployment process is worked out and the development environment is ready to use.

It will be nice to have something to work on during the community bonding period anyway, since I'm familiar with a lot of the codebase already, and the current codebase isn't very large.

The Debian package would be made at the very end after the entire PTS is complete, correct?

Instead of a weekly iterations, wouldn't deploying every time one part of the project is finished be better?

- the REST API is nice but I would not prioritize it too much... ok, to
bring it on par with what the current SOAP interface does, but we
won't add subscription management via OAuth or anything like that at the
start of the project. That would be a new feature and it's best kept for
the end.

Alright. I guess the REST API won't take two weeks then, just one week should do. I still feel working on the REST API before other things like the email or web interface would benefit the developer of the Android app, but I could be mistaken.

I've added an extra week for scalability analysis and performance benchmarking. I think it would be a good idea to do some load testing during this period as well, to see how the PTS and the server it's hosted on perform under heavy traffic.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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

I was also hoping to get your views on generating RDF/XML via django-rdf. Other than possible performance issues, do you think this package is good enough for our purposes or will I have to write some code myself? Will we need to generate both Turtle and RDF/XML?

Olivier said in the other thread:

I guess HTML is of course a priority (hence Web templates alread
mentioned), but other formats may require more structured
"serialisation", maybe quite close to the underlying Model of the Python
objects handled by the core of the PTS.

Which is why I'm hoping just automatically converting objects should be good enough.

--
-Apoorv