1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
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.
|
