Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

[Rich Freeman <rich0@gentoo.org>]

On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> I don't consider a recommended style message to be 'broken' just
> because it's not listed in the devmanual/PMS/etc as a requirement.
> The implementation of it, on the other hand, yes that could be broken
> and in this case should be fixed if we keep the check around.
>

If we are bothered enough by something to have repoman check it, we
can be bothered enough to add it to the devmanual.

I think we need to decide whether we care about periods at the ends of
DESCRIPTIONs.  If we do, then it should be a warning and devs should
fix their ebuilds at the next convenient opportunity.  If we don't,
then let's just drop the warning.

I'm fine with the separation of hard/soft errors, because some issues
could be situational and left to developer discretion.  However, we
wouldn't want to hide those, because if a dev introduces a new issue
we don't want them to not see the warning.

If somebody has a whitespace issue they should get a warning.  They
should be doing a scan before commit, and they should generally take
the time to fix the issue, even though it is just style.  What is the
point in having a style guideline if half of us are just going to
ignore warnings related to it.  That doesn't mean that our style
guidelines have to be over-the-top - the solution to that is to drop
requirements that aren't important, not to hide them.

If somebody wants to come up with a bunch of extra optional repoman
warnings for stuff like style, I think their time would be better
spent coming up with an ebuild pretty-printer or something which just
fixes things instead of whining about things that aren't policy.

Ultimately quality has to be something we invest in for each other's
sake.  If a rule isn't really benefiting anybody, then it doesn't
belong.  Within reason good style helps us all out - bash doesn't care
if the whole ebuild fits on one line with all the phases/variables/etc
in semi-random order, but we impose some sane style so that we can
work in the tree and not rip our eyes out.

--
Rich