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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
