Hello Jonathan, On Mon 06 Aug 2018 at 06:24PM -0700, Jonathan Nieder wrote:
> Thanks for explaining your point of view. I agree with relying on > maintainer judgement, and the best way to do that is to avoid having a > requirement in policy at all in some areas. > > I think it really does help to look at the motivating use cases. If > we focus on what it would be a good idea for a packager to do, then > policy would become very long, and it would become much less useful as > a precise source of information about Debian's packaging policies. > Instead, I find it more useful to focus on the non-obvious bits where > having a documented policy can help. This is an important point to bear in mind when working on Policy; thank you for noting it. > If I understand correctly, you're saying that the following fall into > that category: > > - don't abbreviate build commands unless DEB_BUILD_OPTIONS=terse > - don't abbreviate test commands and output unless > DEB_BUILD_OPTIONS=terse > > Do I understand correctly? Are there more examples in that category, > or could we just document those two? These are the only examples that come to my mind at present, indeed. > [...] >> 1) Add something like "In particular, build command lines should not be >> abbreviated." Then we are not leaving that particular case up to >> maintainer judgement, without removing the general recommendation. > > This wouldn't help Clément's motivating example, since it would not > clarify whether there is additional verbose output he needs to > provide. > >> 2) Add some examples of what should usually not be included, or perhaps >> just say that if some output makes a build log tens of megabytes in >> size, it should not be included. > > I feel that this is trying to solve a problem that doesn't need > solving: packagers generally have good taste, and for most purposes it > is obvious to packagers what outputs they need to include (after all, > the packager is the primary audience of these logs!) Build command > lines really are a special case since they are important to the > toolchain maintainers. > > The size threshold you mentioned would suggest that the Linux kernel > should not support unabbreviated build logs. After reading the message to which I'm replying, I am no longer confident in my previous opinion that recommending verbosity in general, and providing some examples of where verbosity is most important, is better than recommending verbosity in only specific cases (as you advocate). I would like to see opinions about this from people other than the few of us who have been writing to this bug. This bug will be closed on the next upload since we addressed the original submitter's main concern, but if you're still interested in driving this change to recommend verbosity in only specific cases, please do clone this bug, or file a new one (IMO the latter would be more useful at this point in the discussion, but I appreciate that it is more work). -- Sean Whitton
signature.asc
Description: PGP signature
