Added ghost patches support.
[users/seanius/patch-tracker.git] / TODO
1 welcome to the TODO file.
2
3 == short-range TODO ==
4
5 better handling of more exotic patch systems
6
7   for example:
8   - handling cpp processing of dpatch files
9   - handling wierd configuration for simple-patchsys and recusrive dirs
10   - handling when the directory looks like dpatch/quilt but isn't
11
12 code cleanup from really ugly stuff (look for XXX)
13
14 dead code removal/cleanup
15
16   after switching a few design decisions, there's some code that's no longer
17   used or should be removed
18
19 document url-based api more fully
20
21 == medium-range TODO ==
22
23 review db design
24
25   the db schema design is most likely less than optimal, the use of triggers
26   to emulate foreign keys is novel but likely we can remove a few columns and
27   use rowids instead, and possibly lower/optimise the remaining queries.
28
29 remove all the os.system calls
30
31   lots of temporary ducttape via os.system that should go away
32
33 make prettier pages
34
35   they're all xhtml compliant, using css, and based on a single skeleton
36   page so it shouldn't be too much work
37
38 decide how much should be cgi-based and how much should be written
39
40   there's no reason why the entire system can't be generated via cgi-based
41   accessing, but the question is whether it should be, or whether certain
42   componenets should remain static.
43
44 review url-based interface, determine how to make it more flexible hopefully
45 not at the cost of ugly url's or exposing the language.
46
47 == long-range TODO ==
48
49 dynamic info?
50 external data sources?
51
52 == suggestions from others ==
53
54 pabs:
55
56 A couple of suggestions for the patch pages:
57
58 http://patch-tracking.debian.net/patch/debianonly/view/abraca/0.2-2
59 http://patch-tracking.debian.net/patch/series/view/a52dec/0.7.4-11/01-libtoolize
60 http://patch-tracking.debian.net/patch/series/view/a52dec/0.7.4-11/03-soname
61
62 The diffstat should be in a <pre> tag.
63
64 (i think this is already done? -sf)
65
66 The diffstat should link to anchors embedded in the diff for each file.
67
68 Would be nice to extract the patch description/header; stripping the
69 dpatch header, some of the quilt cruft that can happen and whatever else
70 you find, then nicely format that and stick it at the top.
71
72 With source format 3 (quilt) it might be nice to know the diff between
73 the debian/ directory in the orig.tar.gz if any and the debian/
74 directory in the debian.tar.gz.
75
76 A couple of suggestions for the error page:
77
78 http://patch-tracking.debian.net/package/apache/1.3.34-4.1+etch
79
80 The code seems to say that apache doesn't exist, but it does, just that
81 version doesn't. I think it should say version not found and be a copy
82 of the main page for the package.
83
84 The error page does not return a HTTP 404 code, so search engines will
85 index the error pages, which would be bad. 
86
87 General stuff:
88
89 Once packages.d.o links to it, this really needs announcing widely; LWN
90 at the least, might want to talk about it on the debian-publicity list
91 first though.
92
93
94
95 from joss:
96
97
98 I think you could get bonus points for using different colors for
99 co-maintained packages – although I don’t need this personally, I think
100 this will be appreciated by others.
101
102 ...
103
104 Patches in the quilt series and dpatch formats, and sometimes those in
105 the simple-patchsys format as well, have often comments at the top of
106 the file. It would be very nice to see them in the patch summary,
107 together with the diffstat.
108
109
110
111 from azeem:
112
113
114 there are some maintainer overview pages like
115 http://patch-tracking.debian.net/email/pkg-gnome-maintainers@lists.alioth.debian.org 
116 have a high number of packages.  However, not all of them have patches
117 to the upstream source in them and there is no indication on the
118 overview page for which this is the case.  Thus upstream people have to
119 click on every package/version link and check for themselves.  On top of
120 that, it is not immediately clear that there are no upstream patches and
121 people might just click on the Debian dir patch and wonder, see
122 http://www.mail-archive.com/desktop-devel-list@gnome.org/msg14030.html
123
124 I propose to make it visually clear that a given package/version has no
125 upstream patches by either coloring the link differently or somehow
126 otherwise differentiating the two.  A useful heuristic could be:
127
128 15:02 < seanius> so basically you mean to look for any changes including
129         ".", excluding "./debian", and including "./debian/patches"
130
131 Everything else is probably broken packaging and not worth the hassle.
132
133
134 == new "manydiffs" architecture ==
135
136 DSA is currently working on creating an official snapshot.debian.org
137 service, which contains a historical archive of all packages ever
138 uploaded into debian.  obviously this has some interesting implications
139 for a service like this.
140
141 === Modelling changes ===
142
143 the current model is completely release (or ftp-archive) centric,
144 where packages are tightly associated with the respective release of
145 the package, and information is lost some time after the package is
146 superceded or otherwise removed from a debian release (the caching
147 implementation extends the life just a bit, but still...).  In the
148 new system, packages *may* have an association with a specific release,
149 or they may not.
150