I agree pull requests should not contain unrelated formatting changes, but
I don't see too much of an issue if the changes are a) all in the same area
as the functional changes and b) in a separate commit from the functional
changes.
I think a bulk reformat + automatic format checking is probably the only
way we are actually going to get any sort of consistent formatting at this
point.
> If we do adopt automatic code style checking, we could get even more
> benefit by using a code quality tool. The remaining issue is how
> strictly we enforce the rules and at what point. If we can do it on
> Travis CI, then I think it will be workable. The problem is that we
> still have cherry-picks and direct pushes that will circumvent Travis CI
> and might lead to false blaming of later pull requests (no different to
> unit test failures, which have the same problem).
>
> If we also have a build on ares that does format checking (perhaps
separate from the main build?), we should be able to notify cherry-pickers
of failures due to formatting.
Torben
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
