On 12 April 2014 05:32, Russ Allbery <r...@debian.org> wrote: > So, to take a step back, I think Ian is arguing that, by declaring the > traditional menu system a "should," he's not introducing a problem into > Policy that doesn't already exist, because our current use of "should" is > all over the map.
I think it would be useful to look at this more from a "what are the consequences if a package violates policy (and someone notices)?" There are a bunch of possible consequences within Debian: - the maintainer works out a fix and uploads it - someone else works out a fix and files a bug - someone NMUs the package - the package gets removed from Debian by ftpmaster - some tool prevents the package from building/being uploaded (eg debhelper, lintian) - the package doesn't get shipped in testing / stable - someone takes over maintenance of the package - it becomes okay to NMU the package without notifying the maintainer first - it's okay to upgrade the bug to critical/serious/important - it's okay to downgrade the bug to minor/wishlist - it's okay to close the bug without fixing it - someone files a bug - lintian/piuparts/etc reports an error I'd divide them up into: - someone spends their time fixing the issue - bad things happen to the unfixed package - how likely someone is to notice Obviously the most important/useful part of those is categories is getting someone to fix the damn thing, but policy (and release managers and ftpmaster et al) only really get to choose which bad things happen as a consequence of non-compliance. Perhaps there's another set of consequences along the lines of "maintainer gets told off on irc, maintainer gets flamed on -devel, maintainer gets a scolding by the tech-ctte, maintainer no longer gets free valve games, maintainer gets kicked out of debian" that should be considered; I don't think I'm a fan though. > I agree with that statement as far as it goes, but I don't think it's a > very useful observation. Because usage of "should" is currently all over > the map, it doesn't provide any clear guidance to the packager, which is > what the goal should be. "Providing guidance to the packager" sounds to me more like the first group of advice "here's what's important, here's where you should be spending your time to make the most effective contribution to producing a universal free operating system". I think policy's usage of "should" doesn't provide that sort of advice because policy's just not designed for that. > When working on a section of Policy, I try to fix issues like that when we > see them. There are various "should" requirements in Policy that I think > are actually wishlist bugs, among them man pages and doc-base integration. Not having a manpage has traditionally been treated as a real bug, just not an especially high-priority one. What benefit would changing this actually have? I could certainly imagine, say, the DPL and others coming up with a prioritised list of Things To Do that would make Debian way better; but I don't think it's really policy's job to decide "oh, manpages aren't important any more, .desktop files are where it's at". Everything in /usr/bin should have a manpage, everything that should show up in desktop menus should have an appropriate menu file. Not having them is a bug, with all that entails, though not severe enough to warrant dropping the package entirely. But that's as far as policy should go -- Debian has lots of bugs, which ones get fixed first is an entirely separate matter. > 1. Should programs that make sense in the context of a typical DE (I > realize there's some fuzziness around this) all have desktop files? If > so, what level of Policy requirement should that be? (Please be more > specific than "should" -- maybe talk in terms of expected bug > severities? "should" is still defined in terms of expected bug severities, isn't it? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] So I would say: - yes, they should - the consequence of not having them should be a normal severity bug - lack of a .desktop file shouldn't result in the package being dropped from testing etc - NMU policy for adding .desktop files should be decided outside of -policy > 2. What level of Policy requirement is providing traditional menu files in > individual packages, using the same terminology? I don't see the value in the traditional menu -- from Ian's mail: "The trad menu is supposed to contain pretty much everything that can be executed, [...]. Conversely, the desktop menu is supposed to contain only a subset of programs that are considered useful for users to find and invoke via a menu." If the desktop menu already contains everything that's useful for users to find and invoke via a menu, then everything additional that the trad menu does is by definition useless (for users who want to do menu things, anyway)... And if it's changed so it doesn't do anything additional, what's the point? So based on that I would say: - requirement that they should *not* be present - consequence of having them should be a minor bug But I don't even know if I'm using desktop menus or trad menus, so... > * How Policy should formally represent the distinction between different > levels of requirements. FWIW, I think policy should be distinguishing whether its recommendations are requirements for distribution (legal issues, dependency errors), proper practice (ie, it's a bug if you don't do this), or just a good idea to consider (a suggestion from experienced developers/packagers), but beyond that should just be documenting how to make optimal packages assuming infinite time and motivation. I don't know how you could do that more effectively; must/should/may still seems reasonable to me, but it doesn't seem that effective. Splitting them as three separate documents (distro/release requirements, policy, suggested practices) might be an option. Maybe it would be more effective to approach the problem from the other end -- provide a document/site of what the project thinks are the most important things to work on, so that people who want to "force" maintainers into doing things go there rather than debating which verb is used in policy. Cheers, aj -- Anthony Towns <a...@erisian.com.au> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org