Braindump

> Even better would be to call lintian or similar to do the actual checks.
> Some of them are quite complicated.  In fact, checking for copyright files
> is a good example.  This needs to handle cases like /usr/share/doc being a
> symlink to another package.

That's indeed a very good idea.

Debian seems to perform post-build lintian reports and expose then
publicly, right ?

http://lintian.debian.org/reports/full/cprov@gwyddion.com.html#sqcwa

Considering that:

 A. Replacing all the current code for processing uploads by a lintian
based check would be very risky in several aspects;
 B. Having the litian reports available in Soyuz after the uploads
were done would be already highly valuable by itself.

What about implementing the infrastructure to generate lintian reports
for source and binarypackagerelease as a parallel component, pretty
much as we've done for `debdiff` to generate post-upload diffs ?

Every unique source or binary upload would result in a
LintianReportRequest that would be collected and performed ASAP. The
lintian output would be stored as text and indexed, so searches and
full reports would be possible.

We could also store the lintian exit code, in a way that we can trace
uploads that should be rejected according litian but passed LP checks
(unfortunately the opposite won't be possible).

Anyway, once we feel comfortable with lintian accuracy and maintenance
issues (see below) the upload-check migration should be smooth.

What do you think ?

The main issue with using debian-tools for performing tasks inside LP
code is the difference between production and development versions, it
was a PITA to make the tests cope with different debdiff & patchutils
version, requiring some dapper backports. Regardless the decision
about lintian reports generation, do you see anything we could do to
make it easier ?

Well we could certainly maintain and ship the tools we use inside LP
tree, but it just changes the address of the problem, isn't it ?

Summary

This should provide an overview of the issue/function/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. Mention tables being created.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log.

It is mandatory.

Rationale

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

Use cases

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Schema Changes

Migration

Include:

Unresolved issues


CategoryProposal

Soyuz/Specs/LintianReports (last edited 2009-01-08 19:57:49 by sinzui)