Re: Getting collaberative maintainace up (Re: Upcoming NMU)
On Mon, Feb 02, 2004 at 10:18:33AM +1100, Steve Kowalik wrote:
> On Sun, 1 Feb 2004 19:54:43 +0100, Jeroen van Wolffelaar uttered
> > <possibly dangerous (for me) rant>
> > It always stroke me as odd that there exists both linda and lintian.
> > Isn't it possible to have lintian include arbitrary executables as
> > tests, so that python-only tests can be simply plugged into lintian, and
> > then drop linda? AFAICS, the interface could be very simple: just echo
> > the I/W/E: lines, and keep existing lintian structure.
> >
>
> Gee, way to just fob off over 2 years of work of mine. I feel so much
> better knowing that my checks will be plugged into Lintian, and my
> 1,000 lines of base code will just be "dropped".
Hm, I should have mentioned I did not look into linda's sources or in
fact I did look very well at all at linda.
Steve, my apologies, I never intended to suggest to drop the whole of
linda, but rather to merge lintian and linda (and I just
happened to know lintian (and perl) better, otherwise I probably would
have suggested it the other way around: integrating lintian into linda).
My point stands, that linda and lintian (as linda's description says:
Linda is not unlike lintian). How perl is best integrated with python,
and/or the other way around, I have no real expertise in (don't know
python, and my perl is also to very well), but I think it would be good
idea to make one 'ubertool' out of two very useful ones.
Since both have few 10's sections, use some kind of lab, and have
similar interfaces, that would make indeed fewer code, but fewer code is
_good_, as it means less maintaining.
I've the feeling this whole linda/lintian thing is mainly a language
issue, and I really see no good reason why not one tool could be
created, execting both perl and python files of checks. Since the
perl/lintian ones are executables, it might be the best way to have a
python interface execute the perl checks...
> Anyway, Linda checks aren't just an executable script, like Lintian's
> are. Spawning 120-odd processes doesn't strike me as the best
> solution. Linda's checks must be execfile()'d by the base code, which
> will register the checks in a registry, and then one by one, the
> classes in the registry are instantiated and run.
ok, but as you of course also know, there are other implementations than
just exec'ing for every test without thought... nothing would prevent an
external caller to call for any set of checks, or even all check labeled
as 'additional-to-lintian'.
> > That would prevent a lot of double work... And easier for the user, as
> > only one tool remains. And existing infrastructure like the global
> > lintian check on the whole archive will for free feature the linda
> > checks too then.
>
> If you check, Linda checks are pretty much the same as the Lintian
> checks, with silly checks dropped, and a few that have been merged,
> and not so many false positives.
Emphasizing my point the code should IMHO be merged, and of all checks
simply the best check should be used. All the duplicate work that gets
done now... that could be spend on fixing bugs that linda/lintian/both
warn about!
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: