[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Plans for squeeze



Hi all,

Before I move into the main topic of this mail: is there any plan to
participate in GSoC 2009?

Now, back on topic, I'd like to see most, if not all, of these changes made
for squeeze:

* 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.

* Support for multi-architecture laboratories. This can be implemented a-la
multi-areas (bw, I didn't really understand why it is "incomplete") 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. 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.

* 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.

* 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.

* 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.

* 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.

* Source package cleanup: {frontend/,}depcheck? private/transtat,
lib/scan_script.pl?

Comments? suggestions? are those goals feasible? 

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net



Reply to: