-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathTODO
79 lines (72 loc) · 3.34 KB
/
TODO
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
search_packages:
- all searches:
- Display "$pkg ($section) shortdesc from stable (or if not available, testing, unstable, ...)"
tersely on one line each, with "#foo" links to what's currently displayed.
- The 'extended' can maybe also have full descriptions then (maybe add did
to _small.db?)
- Unify exact & subword -- reduce naming confusion with 'exact' meaning
either "exactly the same" or "full word"
- When doing substring searches, hilight with html backgroup color (css of
course) the search term
- exact package searches
- substring searches on packages:
- don't allow whitespace in it, warn when people use common wildcards like
*, ?, ^, $ (not possible)
- When overflow, iterate the first couple of packages that *start* with the
substring, if any? Maybe list those first, and only then real substring
search?
- In db, add "abc: too many matches" to postfixes when there's a "abcd: 90
matches" and abce: 90 matches"
- fulltext search:
- in results, show full descriptions, so one sees what's being matched?
- backend:
- Ensure that in _small.db, newest version for each suite is first,
show_package relies on that. So foreach suite, 'newest entry', and only
then, all the other entries
search_contents:
- regain section (main/contrib/non-free) information? It is currently
not available at all.
Static pages:
- try to make it faster
General:
- Try to break everything with empty/short searches
- Check for case sensitive consistency
- Fix assumption that archive doesn't show up in any url, consistency-fy
dealing with archives of a different set than (us, non-us, security)
- grep -ri fixme
- searchon=all -> searchon=descriptions?
- quicksearch box: copy parameters of current search (exact,suite,arch,etc),
or rather, always use defaults? Both have their pro&cons... former is more
obscure, but otoh, for typo fixing more appropriate.
Maybe best of both worlds is 'modify search' below results, where you can
generalize/specificy arch, etc etc?
- In Search.pm, make sure read_entry_small only scans a bit, and not all --
once you have #max_nr_of_suites, you know you won't find the queried suite
anymore, so search further is futile. Maybe the backend could even add a
marker, ignored by read_entry_all, but understood by read_entry_small, that
indicates end of $res2 and start of $res3
- Store in db \1-separated, and split on that, instead of the more fragile
'/, /' split
- Fields we don't handle in any way currently:
Conflicts
Replaces
Enhances
Origin -- not needed
Bugs -- not needed
Task
Python-Version(s) -- not needed
- screenshots - http://bugs.debian.org/262617. Possible filtering for not
displaying the screenshot part:
* http://screenshots.debian.net/json/screenshots contains all available
screenshots (for potential filtered out ones to force-display them)
* filter on debtags: interface::3d interface::framebuffer interface::svga
interface::text-mode interface::web interface::x11
* filter on sections: libs, oldlibs, debug, ... Ask for input.
Cron:
- Verify Release files
- refactorize 100syncarchive* so that there is not so much copied code
Missing pieces from old code:
- search_packages result parser?
reportbug in sarge is completly broken in this regard anyway AFAICT
reportbug in etch works as long as there is the exact hit but
breaks once there is more than one hit