Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > On Wed, Apr 05, 2006 at 02:18:01PM -0700, Russ Allbery wrote:
>> I may well be missing something, as that seemed fairly straightforward, >> so let me know what I didn't notice. consolidate-lintian and >> lintian.log in ~rra on merkel. > Well, you missed the fact that the index file will list all packages, > regardless of suite and arch. The current lintian.d.o interface simply > isn't capable of showing that, so it should be limited. Ah, okay, that's easy enough to do. For right now, we should probably limit to i386 and source (although I see that genlist right now is restricted to source). Hm, suite is a more interesting and challenging problem. The most useful approach for the current lintian pages (which only show each package once) is probably to show unstable, but it looks like the suite isn't captured in the index file? Given that, my first inclination would be to only include the latest version of any given package, but maybe I'm missing something else. Down the road, I think generating a combined log file is the wrong approach; I think it would be better to generate the lintian report pages on the fly out of a database (of some sort; part of the database may be a collection of flat files containing the lintian output and the only database stuff might just be the package metadata). I think we want to index by at least the following: * Package * Suite * Maintainer * Architecture The most common views are going to be "show all lintian warnings for the given source package and any binary packages it produces, looking only at i386 binary packages and the given suite" and "show all lintian warnings for any source or binary packages by the given maintainer in unstable, looking only at i386." The more advanced option would be to suppress other architectures only if the tags duplicated tags already seen for i386. We could toss this into a separate MySQL database, but actually, looking at this data, all of this would already be in the QA information used to generate the current pages. Is that information already stored in MySQL or PostgreSQL or the like? It would be great if it were, since then we could do the queries directly on it, and the only part left would be hunting down the actual log files containing the lintian messages, if any. > I'm not entirely sure yet how this all is going to work together > exactly, there's more things that needs such techinques to show only > particular archs/suites/etc. And the html_reports thingy is still being > a bitch at me, it requires some other permanent-lab internal data... I'll poke at it and see what sort of internal data it's looking for. > Info tags are reported, I think the reporting might hide them indeed... > oh well. Brilliant idea's appreciated :) Once we generate the reports dynamically, that will be easy to handle as another display option. Although I'm not sure about performance issues. Are dynamic web pages generally a bad idea? I have *no* idea what level of traffic we're talking about here. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
