Hi Attached is the "diff" between the proposed topics and the resulting gobby document (also attached) at the end of the BoF. People suggested a few "extra" checks, which I believe would mostly be in unofficial checks. The proposer of "Team vendor global overrides" seems to be satisfied when I noted that the Vendor Profiles should be able to do that. I proposed we could use a Domain Specific Language (DSL) for some of our checks (particularly thinking of checks/files). The feedback included two good counter arguments, the first being we would still need a general purpose language (Perl itself) and the second was that the DSL might end up being just as complex a language as Perl. Doko and some others showed up and asked about scanning build logs (also filed as #628518). Personally I had two concerns here, the issue of injecting the build logs into the analysis. Raphaël Hertzog said there was a request to include (a reference to?) the build logs in the changes file. My other issue was that extracting anything useful from the log is difficult at best. From what I gathered, the general idea of the check was to see if the package was not respecting compiler flags. Documentation on writing checks was requested. It would probably be a good idea to repeat/stress some of the important design choices in said documentation (even if they are already mentioned in the User Manual). I asked if anyone found our "cant fix" bugs useful. That is, the bugs we mark wontfix, but keep open because hopefully someone or some other project will pick them up and do it. Unfortunately I did not get much of an answer on that. I believe Paul Wise brought up the topic of "What to do about people abusing lintian overrides". I have on occasion seen some packages containing overrides for everything even things that could be trivially fixed. In relation to that, people asked about comments for overrides... That would be #512901. :) Until a recent commit, the User Manual has always mentioned that the "Lintian Maintainers" are filing bugs based on the tags, so "don't do that". When bringing up this note, Lucas Nussbaum mention he already has some "bug-filing scripts" to avoid filing duplicate bugs. In case we are interested in doing something in this area, the hard part might be done for us already. People recommended reading debian-mentors for finding new things to check for. I thanked for the proposal and said we had enough unfixed bugs about new tags to have time to actually go look for new ones to do. But I encouraged people to file bugs if they found something. I also caught up with Emmet Hikory about setting up a "lintian.ubuntu.com"-like thing. He had some old changes for making it brandable and less hard-coded. He asked me to nag him about it after DebConf. Finally, the FTP masters are needing an update of Lintian to allow debs compressed with .xz into the archive, so I will be doing a release soon. ~Niels
Attachment:
bof-output.diff
Description: application/wine-extension-patch
Possible topics (incl. some from last years BoF[1]):
* Lintian "extras" (team/vendor specific checks)
- No official progress
- Vendor profiles can be abused for "adding" extensions
(not "officially" endorsed though)
- resource intensive checks and other external checkers
- W: code-quality-is-bad-according-to-{cppcheck,coccinelle}
- W: desktop-file-has-warnings-from-desktop-file-validate
- Checks requiring Internet access?
- W: homepage-is-spam-site
- W: package-should-have-screenshot
- Team vendor global overrides (profiles)
* Tag (description) translations
* Supporting "Lintian.d.o"-like setups for derivatives/third-parties[2]
- Currently rather inbred code ("it's more awkward than it should
be")
* Lintian Static Analysis Framework[3]
- Expose parts of Lintian as API/Framework for others
(e.g. liblintian-perl)
- Mirror sync support
* Multiple-version/architecture support (#632115 and [4])
- Handling processing of pkg $ver1 and $ver2 at the same time
- Opens the door for limited doing "upgrade" checks.
- Not a replacement piuparts
- Maybe as a separate tool using "liblintian-perl"?
* Maintenance/Attracting more (diverse) developers
- Out-source check maintenance to relevant parties
- (e.g.) Python related checks have been outdated for a while.
- A lot of check/tags use a simple diagnosis
- File X in dir Y requires/implies strong dependency on Z
(checks/files should have a number of examples)
- Write a simple Domain Specific Language for common cases?
- as simple as possible
- general lang. features are needed
* Analyzing build logs for common (potential) problems? (idea of doko)
* Documentation on writing checks
- Writing tests
- focus on design limitations
* "cant fix bugs"
* comments for overrides on l.d.o
* contact maintainers over-using overrides
* filing bugs based on lintian tags
contact lucas: his scripts can help avoid filing duplicate bugs
* people interested in finding ideas for new checks, follow the debian-mentors
list and review packages then add lintian checks
* Your idea/proposal here
[1] http://lists.debian.org/debian-lint-maint/2010/08/msg00012.html
[2] http://lists.debian.org/debian-lint-maint/2011/07/msg00039.html
[3] http://lists.debian.org/debian-lint-maint/2011/07/msg00044.html
[4] http://lists.debian.org/debian-lint-maint/2011/07/msg00112.html