Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )
Date: Tue, 12 Aug 2014 17:25:52
In Reply to: Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings ) by Ian Stakenvicius
1 On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius <axs@g.o> wrote:
2 >
3 > I don't consider a recommended style message to be 'broken' just
4 > because it's not listed in the devmanual/PMS/etc as a requirement.
5 > The implementation of it, on the other hand, yes that could be broken
6 > and in this case should be fixed if we keep the check around.
7 >
9 If we are bothered enough by something to have repoman check it, we
10 can be bothered enough to add it to the devmanual.
12 I think we need to decide whether we care about periods at the ends of
13 DESCRIPTIONs. If we do, then it should be a warning and devs should
14 fix their ebuilds at the next convenient opportunity. If we don't,
15 then let's just drop the warning.
17 I'm fine with the separation of hard/soft errors, because some issues
18 could be situational and left to developer discretion. However, we
19 wouldn't want to hide those, because if a dev introduces a new issue
20 we don't want them to not see the warning.
22 If somebody has a whitespace issue they should get a warning. They
23 should be doing a scan before commit, and they should generally take
24 the time to fix the issue, even though it is just style. What is the
25 point in having a style guideline if half of us are just going to
26 ignore warnings related to it. That doesn't mean that our style
27 guidelines have to be over-the-top - the solution to that is to drop
28 requirements that aren't important, not to hide them.
30 If somebody wants to come up with a bunch of extra optional repoman
31 warnings for stuff like style, I think their time would be better
32 spent coming up with an ebuild pretty-printer or something which just
33 fixes things instead of whining about things that aren't policy.
35 Ultimately quality has to be something we invest in for each other's
36 sake. If a rule isn't really benefiting anybody, then it doesn't
37 belong. Within reason good style helps us all out - bash doesn't care
38 if the whole ebuild fits on one line with all the phases/variables/etc
39 in semi-random order, but we impose some sane style so that we can
40 work in the tree and not rip our eyes out.
42 --
43 Rich