launchpad developmentLaunchpad entry: none yet
Created: 2008-05-15 by CelsoProvidelo
Contributors:
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:
- data migration, if any
- redirects from old URLs to new ones, if any
how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the rollout template.)
