I think that some style updates that can also have impact on the code should be added even now. For instance, indentation probably should be accepted now as non-four space indent and mixing tabs with spaces may have undesirable effects.
I do see that attribution is lost but on the other hand it's better to have style changes made in a "style PR" than to have style fixes mixed in with someone else's actual code changes because they had to change the style of unrelated sections so they could read and understand it. That practice hampers both attribution and understanding of the actual meaningful changes. Enforcement is great and I'd love for us to have that. But enforcement is easy if you have a clean base (run checker -- if output is clean, commit) and hard if you have a base that already fails 2000 tests (run the checker on upstream. Record the errors. Run the checker on the code with the PR applied. Compare errors and decide whether any of the errors are new). -Toshio On Tue, Jul 28, 2015 at 8:54 AM, Brian Coca <[email protected]> wrote: > So we have some disagreement here, I would hold off on any style PRs. > > I find that style updates w/o having enforcement first will just be a > waste of everyone's time as code will drift from the style as we > accept PRs. > It also breaks attribution and makes it harder for us to look at > why/when was a code made in such a way, specially when judging new > changes against that code. > Aside from forcing many rebases for style reasons, not because bugs > got fixed or features added (which already cause many PRs to need > rebases). > > Considering our current backlog and issues before us, I really don't > want to spend time in minor style changes nor reviewing them. > > If some code is so bad as to be a great maintenance burden, I would > consider a PR, for the rest I think we can live with extra or missing > spaces around operators. > I think we should look at style enforcement way before we even think > about allowing for style only PRs and only after we have dealt with > the many other issues I consider higher priority than this. > > -- > Brian Coca > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAJ5XC8%3DzT2xXYFs_c%3DE9FWoh2PzEWM0-JOcuSkMSMSHcQH5N%2Bg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAG9juEqo-Y%2BR3uzcyQTnibL5iMr0XS6Mbb4qM96AbXE5oe5diA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
