]> git.deb.at Git - deb/packages.git/blob - TODO
config: Add all our sponsors
[deb/packages.git] / TODO
1 search_packages:
2 - all searches:
3   - Display "$pkg ($section) shortdesc from stable (or if not available, testing, unstable, ...)"
4     tersely on one line each, with "#foo" links to what's currently displayed.
5   - The 'extended' can maybe also have full descriptions then (maybe add did
6         to _small.db?)
7   - Unify exact & subword -- reduce naming confusion with 'exact' meaning
8         either "exactly the same" or "full word"
9   - When doing substring searches, hilight with html backgroup color (css of
10         course) the search term
11 - exact package searches
12 - substring searches on packages:
13   - don't allow whitespace in it, warn when people use common wildcards like
14         *, ?, ^, $ (not possible)
15   - When overflow, iterate the first couple of packages that *start* with the
16         substring, if any? Maybe list those first, and only then real substring
17         search?
18   - In db, add "abc: too many matches" to postfixes when there's a "abcd: 90
19         matches" and abce: 90 matches"
20
21 - fulltext search:
22   - in results, show full descriptions, so one sees what's being matched?
23
24 - backend:
25   - Ensure that in _small.db, newest version for each suite is first,
26         show_package relies on that. So foreach suite, 'newest entry', and only
27         then, all the other entries
28
29 search_contents:
30 - regain section (main/contrib/non-free) information? It is currently
31    not available at all.
32
33 Static pages:
34 - try to make it faster
35
36 General:
37 - Try to break everything with empty/short searches
38 - Check for case sensitive consistency
39 - Fix assumption that archive doesn't show up in any url, consistency-fy
40   dealing with archives of a different set than (us, non-us, security)
41 - grep -ri fixme
42 - searchon=all -> searchon=descriptions?
43 - quicksearch box: copy parameters of current search (exact,suite,arch,etc),
44   or rather, always use defaults? Both have their pro&cons... former is more
45   obscure, but otoh, for typo fixing more appropriate.
46   Maybe best of both worlds is 'modify search' below results, where you can
47   generalize/specificy arch, etc etc?
48 - In Search.pm, make sure read_entry_small only scans a bit, and not all --
49   once you have #max_nr_of_suites, you know you won't find the queried suite
50   anymore, so search further is futile. Maybe the backend could even add a
51   marker, ignored by read_entry_all, but understood by read_entry_small, that
52   indicates end of $res2 and start of $res3
53 - Store in db \1-separated, and split on that, instead of the more fragile
54   '/, /' split
55 - Fields we don't handle in any way currently:
56   Conflicts
57   Replaces
58   Enhances
59   Origin    -- not needed
60   Bugs      -- not needed
61   Task
62   Python-Version(s) -- not needed
63
64 Cron:
65 - Verify Release files
66 - refactorize 100syncarchive* so that there is not so much copied code
67
68 Missing pieces from old code:
69  - search_packages result parser?
70    reportbug in sarge is completly broken in this regard anyway AFAICT
71    reportbug in etch works as long as there is the exact hit but
72    breaks once there is more than one hit