Re: Plans for squeeze
Russ Allbery wrote:
> Raphael Geissert writes:
>
>> Before I move into the main topic of this mail: is there any plan to
>> participate in GSoC 2009?
>
> I don't have any time to be a mentor or to put together project ideas. I
> think it would be great if someone did, but realistically given the
> timeframe it seems unlikely.
Well, the rest of this email was also an attempt to encourage some feedback
as to what could be proposed to students :).
>
>> * Change the default output format. The EWI format lacks the severity
>> and certainty information which is the main change in 2.x.x and thus
>> should be dropped in favour for another one. This of course would
>> require a transition plan and the old output formatter to still be made
>> available so that the transition is not blocked until the apps relying
>> on lintian's output parse the new default.
>
> I'm not sure about this one, honestly. I think there's something to be
> said about the simplicity of this mapping, and we do make the additional
> information available in the long description. But maybe I just don't
> like change. :) I think getting more input on this would be good,
> though.
My concern is that the EWI code doesn't tell much, and a lot of people
ignore I tags just because they think they are not that important; although
most indicate some sort of bugs in the package.
>
> We probably need to put together some more criteria for classification and
> do some more tag review. We can get a fairly good read on certainty from
> false positives and overrides, for instance.
Sure, although it would help if people added comments to the override files
or at least in the changelog :-/
>
>> * Support for multi-architecture laboratories. This can be implemented
>> a-la multi-areas (bw, I didn't really understand why it is "incomplete")
>
> I thought I responded to your patch with the specific details of what else
> needs to be done, and I hadn't seen a further response after that. Maybe
> Gmane dropped the message for some reason? The main change, IIRC, is that
> the package list format needs to be changed to include the archive area so
> that we can display that information on the lintian.d.o web pages.
If that was the problem, I think I already addressed those in the last patch
I sent to the BTS[1]; you later sent [2] where you removed the 'patch' tag.
[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516530#57
[2]http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;bug=516530
> > and by creating binary-<arch> dirs instead of just 'binary', and the
> > latter would be a symlink to binary-i386 for the sake of compatibility
> > with external scripts. There would also be binary-all, which would be
> > handled especially by lintian.
>
> That works.
>
Forgot to mention: I think the easiest way, for now, to support multi-arch
lintian labs would be by generating a lintian.log for each architecture
being tested. The rationale is that neither the internal nor external
(non-lintian) infrastructures support multi-arch output (they all use EWI
code which, again, lacks important information).
>
>> As for multi-repository labs I guess they could be separated under a
>> different directory of the lab; say
>> path/to/lab/{unstable,experimental}/{binary,source}, basically a
>> reporting/harness hack which would use a different lab directory.
>
> I'd like to have a merged report across multiple archives, but since I
> need this for my day job, I can probably also spring regular work time to
> work on this eventually (but likely not before this summer).
>
Ok
>> * Call for feedback. I've asked, IIRC, twice in some channels such as
>> #debian-devel and #debian-mentors if anyone had ideas for new checks, or
>> any other kind of feedback and both times I got some good feedback that
>> later resulted in new checks or feature requests. Although everyone has
>> always been able to file a report, I think something less formal is
>> needed where people can throw random ideas that can later be
>> discussed. I've perceived some sort of fear to file requests.
>
> There's a whole ton of implementable stuff already in the BTS, so I'm not
> personally feeling the need to actively seek out more input in order to
> have more things to work on. (Mergeable patches are always good, though.)
> Work on false positives and tightening existing tests is, to me, somewhat
> more useful than adding completely new tests, although of course the best
> path forward for Lintian is a balance of both of them.
>
Sure; but I think it is better to have plenty of suggestions than very few
of them (not exactly the case here, but I guess you get my point :).
> That's not to say I think this is a bad idea, just more explaining why I
> haven't been doing this personally. But then, on most projects I work on,
> I tend to be the one who does cleanup and refactoring and is more
> conservative about adding new code. :)
Well, I try to cover more and more issues, while trying to avoid bad
side-effects. This reminds me that I wanted to setup a lintian lab at
home, where I could test changes in scenarios not, yet, covered by the test
suite.
>> * Ship reporting/ in the package; there's no need to keep this only for
>> lintian.d.o, and exposing it more would allow it to be tested even
>> further.
>
> The way I'd prefer to do this is to turn the reporting framework into a
> regular program that we can document and install in /usr/bin. This would
> require redoing some of the way that Lintian handles these things and
> probably reshuffling some stuff into modules.
That's exactly what I meant, looks like I didn't explain myself very well.
>
> This too is something that I'll want for my day job.
>
>> * Source package cleanup: {frontend/,}depcheck? private/transtat,
>> lib/scan_script.pl?
>
> Yeah, we should figure out what to do with that stuff. I don't know if
> debcheck in particular has anything to do with the version that's being
> run across the archive or whether it should.
>
AFAIK debcheck (qa.d.o stuff) != depcheck; and debcheck is written in python
and lives under qa's svn repository.
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: