Lisandro Damián Nicanor Pérez Meyer writes ("Bug#741573: Two menu systems"):
> Then we have a "double standard" here. For some cases we (as in "the
> project") consider "should" as Stuart and I described it before, but
> we do *also* consider it a "may" for some cases, as Ian has just
> pointed it out.Can you come up with any examples where "should" is used in a way that _does not_ permit a maintainer to disregard it if it appears to be a more work than they care to put in ? I had a quick look at an arbitrarily chosen section (10, as it happens, on "files"), and there are a lot of uses of "should" which are probably bugs if not followed - but none of those are any particular effort to comply with. Here are the shoulds that seem to me like they might involve some > actual effort: 10.1 | builds to include debugging info by default | builds should turn on warnings 10.2 | static libraries not to use -fPIC unless discussed | scripts to use set -e (not limited to Debian-authored ones!) | perl scripts to check errors (not limited to Debian-authored ones!) | avoid [t]csh for scripting (not limited to Debian-authored ones!) 10.7.1 | script containing config should be treated as config [ok, bored now] There are a couple of these that probably should be "must". For the rest it is IMO acceptable to upload a package which violates them, if the maintainer doesn't feel like tackling that particular problem. Foe example, if the upstream build system is particularly intractable and makes it difficult to sanely specify compiler flags, then it's acceptable (but of course undesirable) to let the upstream build system have its way. If the upstream package comes with tcsh scripts or perl scripts that have shoddy error handling or sh scripts that don't say set -e, those things are probably bugs - but I don't necessarily expect the maintainer to fix them all. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
