On Wed, Jan 09, 2008 at 12:54:32PM -0800, Don Armstrong wrote: > On Wed, 09 Jan 2008, Anthony Towns wrote: > > Uh, you're kidding right? The BTS's own search engine won't turn up hits > > outside the BTS, as a trivial example... > It's far superior to google for searching for results *in* the BTS. > That's obviously the subtext of my statement. Well, that's certainly true while google's directed to not index results in the BTS; if that weren't the case Google would do a respectable job. But the more common case (IME) is when you don't have a site: restriction and you're happy to have external pages appear if they're relevant (eg, related launchpad bugs, or discussion on lists that didn't get Cc'ed to the bug, etc). Likewise, the BTS search engine can't take into account external hints about which bugs are more likely to be relevant, while Google and other web search engines can. (In practice, with google barely indexing anything in the BTS yet; lookup for bug#459818 by googling for `medium dhclient-script' works fine; using hyperstraier on merkel takes ages and doesn't return any hits) > > Getting smarturl.cgi properly done is still probably the real solution. > It's not clear that that's actually the right way forward, but it may > be a solution. It's certainly /a/ solution. What else is an option? I think any solution should at least provide simple to access pages for bug#, package and source with at most one subdirectory (bugs.d.o/bug/123413, eg), and they should be dynamically generated, which means you've got to have a CGI script determining what to display based on pathnames. I'd call anything doing that "smarturl", pretty much. Cheers, aj
Attachment:
signature.asc
Description: Digital signature