| 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 |
> |
| 8 |
|
| 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. |
| 11 |
|
| 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. |
| 16 |
|
| 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. |
| 21 |
|
| 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. |
| 29 |
|
| 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. |
| 34 |
|
| 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. |
| 41 |
|
| 42 |
-- |
| 43 |
Rich |
Archives