Re: Plans for squeeze
Raphael Geissert <atomo64+debian@gmail.com> 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.
> * 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.
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.
> * 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.
> 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.
> 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).
> * Modularisation of code shared between devscripts and lintian. At the
> moment both lintian and devscripts share some bits of code for the
> bashisms and watch file -related checks. The idea is to move that code
> into independent modules.
This would be great.
> * 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.
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. :)
> * Removal of the unpack/ scripts. As already mentioned a couple of times
> in the past, they should all better live under collection/. Even the
> list-* scripts should find a better home.
Agreed. The list-* scripts really want to be modules anyway.
> * 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.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: