-search_packages.pl:
+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 do exact lookups, but use '^' prefix token
- - only do for >= 2 characters
- 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
matches" and abce: 90 matches"
- fulltext search:
- - Max 100 results
- - Better exact=1 performance by indexing per word?
+ - 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