08-Mar-2013 18:32, Leandro Lucarella пишет:
Dmitry Olshansky, el 8 de March a las 12:33 me escribiste:
There is got to be more effective process to merge stuff. Current
situation involves ping-pong between commiter/reviewer and
contributor on every minor nit there is. That basically involves
reviewing the same exact code few times over as cleanup arrives some
days later. And even when contributor think he did cleanup
something, he/she may as well miss what's the deal and the cycle
repeats.
Instead it's definitely possible for committer to checkout the pull,
do an extra cleanup commit (with automatic tool possibly, like
detab/toln and I'd love to see official "indent" for D) and push it
to the main repo. (Or squash the commits. This doesn't cancel out
reviewing anything non-trivial by at least 2 persons.)
I think this is the wrong approach. People need to learn how to do
a proper pull request, you can't get the committers doing cleaning work
after contributors. Is a learning process, once you get it right, your
pull requests shouldn't too many cycles to get accepted.
I would have agreed if it were not for these things:
a) The learning process is an evolution of knowledge, thus you've got to
be nice to newbies. This means trying to not overwhelm them with minor
details, fascist style requirements and whatnot on the first pulls. (+
learn by example - show the commit that cleans things up and insist on
following conventions etc. next time around)
b) The time the pull takes to be accepted is no less then one month
unless it gets pulled in during the first few days. Typical RTT between
committer-contributor of up to one-two week(s).
c) Committer already spent as much (if not more) time by looking through
the pull. Doing a trivial cleanup after that should be a semi-automated
five minute job.
--
Dmitry Olshansky
