welcome to the TODO file.

== short-range TODO ==

better handling of more exotic patch systems

  for example:
  - handling cpp processing of dpatch files
  - handling wierd configuration for simple-patchsys and recusrive dirs
  - handling when the directory looks like dpatch/quilt but isn't

code cleanup from really ugly stuff (look for XXX)

dead code removal/cleanup

  after switching a few design decisions, there's some code that's no longer
  used or should be removed

document url-based api more fully

== medium-range TODO ==

review db design

  the db schema design is most likely less than optimal, the use of triggers
  to emulate foreign keys is novel but likely we can remove a few columns and
  use rowids instead, and possibly lower/optimise the remaining queries.

remove all the os.system calls

  lots of temporary ducttape via os.system that should go away

make prettier pages

  they're all xhtml compliant, using css, and based on a single skeleton
  page so it shouldn't be too much work

decide how much should be cgi-based and how much should be written

  there's no reason why the entire system can't be generated via cgi-based
  accessing, but the question is whether it should be, or whether certain
  componenets should remain static.

review url-based interface, determine how to make it more flexible hopefully
not at the cost of ugly url's or exposing the language.

== long-range TODO ==

dynamic info?
external data sources?

== suggestions from others ==

pabs:

A couple of suggestions for the patch pages:

http://patch-tracking.debian.net/patch/debianonly/view/abraca/0.2-2
http://patch-tracking.debian.net/patch/series/view/a52dec/0.7.4-11/01-libtoolize
http://patch-tracking.debian.net/patch/series/view/a52dec/0.7.4-11/03-soname

The diffstat should be in a <pre> tag.

(i think this is already done? -sf)

The diffstat should link to anchors embedded in the diff for each file.

Would be nice to extract the patch description/header; stripping the
dpatch header, some of the quilt cruft that can happen and whatever else
you find, then nicely format that and stick it at the top.

With source format 3 (quilt) it might be nice to know the diff between
the debian/ directory in the orig.tar.gz if any and the debian/
directory in the debian.tar.gz.

A couple of suggestions for the error page:

http://patch-tracking.debian.net/package/apache/1.3.34-4.1+etch

The code seems to say that apache doesn't exist, but it does, just that
version doesn't. I think it should say version not found and be a copy
of the main page for the package.

The error page does not return a HTTP 404 code, so search engines will
index the error pages, which would be bad. 

General stuff:

Once packages.d.o links to it, this really needs announcing widely; LWN
at the least, might want to talk about it on the debian-publicity list
first though.



from joss:


I think you could get bonus points for using different colors for
co-maintained packages – although I don’t need this personally, I think
this will be appreciated by others.

...

Patches in the quilt series and dpatch formats, and sometimes those in
the simple-patchsys format as well, have often comments at the top of
the file. It would be very nice to see them in the patch summary,
together with the diffstat.



from azeem:


there are some maintainer overview pages like
http://patch-tracking.debian.net/email/pkg-gnome-maintainers@lists.alioth.debian.org 
have a high number of packages.  However, not all of them have patches
to the upstream source in them and there is no indication on the
overview page for which this is the case.  Thus upstream people have to
click on every package/version link and check for themselves.  On top of
that, it is not immediately clear that there are no upstream patches and
people might just click on the Debian dir patch and wonder, see
http://www.mail-archive.com/desktop-devel-list@gnome.org/msg14030.html

I propose to make it visually clear that a given package/version has no
upstream patches by either coloring the link differently or somehow
otherwise differentiating the two.  A useful heuristic could be:

15:02 < seanius> so basically you mean to look for any changes including
        ".", excluding "./debian", and including "./debian/patches"

Everything else is probably broken packaging and not worth the hassle.


== new "manydiffs" architecture ==

DSA is currently working on creating an official snapshot.debian.org
service, which contains a historical archive of all packages ever
uploaded into debian.  obviously this has some interesting implications
for a service like this.

=== Modelling changes ===

the current model is completely release (or ftp-archive) centric,
where packages are tightly associated with the respective release of
the package, and information is lost some time after the package is
superceded or otherwise removed from a debian release (the caching
implementation extends the life just a bit, but still...).  In the
new system, packages *may* have an association with a specific release,
or they may not.