On Mon, Mar 17, 2008 at 05:18:20PM -0700, Russ Allbery wrote: > The last part is certainly true, although I don't think that makes the > check at that point unuseful. The initial upload is the point at which > it's the most likely that significant misunderstandings or structural > flaws will show up. For example, someone who doesn't realize they > shouldn't repackage upstream without a good reason will tend to do it > every time, and hence it will show up in the initial upload. The bugs > introduced later tend to be (although aren't always) less rooted in basic > misunderstandings.
The check is probably not unuseful. Instead of a report or a series of bugs, however, the result of that check is sometimes a REJECT and thus a need to re-upload to NEW. > As for having this be outside the scope of NEW and something we can check > later, I agree in principle, but in practice packages are rarely ever > looked at again in a comprehensive way after NEW except via automated > checks. I'm painfully aware of just how limited Lintian is. There are a > lot of problems that it just isn't in a position to notice. If we had a > regular practice of more detailed package audits of existing packages, > that would be great, but that generally doesn't happen until packages > change maintainers. In the meantime, NEW is structurally our best shot at > this. I'm not convinced that the majority of these uncaught problems are significant enough to worry about. I would be surprised, for example, if using a non-pristine tarball was ever regarded as a release-critical issue. Why slow down NEW processing to check things like that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
