On Jul 28, 2011 6:01 PM, "MZMcBride" z@mzmcbride.com wrote:
Brion Vibber wrote:
On Thu, Jul 28, 2011 at 3:09 P If you're not sure, those are *all* better places to try something out
than
committing directly to trunk without talking to anybody or getting any feedback.
It's a bit difficult to get comments/review in the CodeReview comments
area
if you haven't made the commit yet. ;-)
If you made the commit and received feedback about it in CR, continuing discussion there before making an amended commit -- especially when fixing something that was reverted -- seems a good fit.
That can save committers and reviewers alike from the pain of a second or third breakage+revert/rushed fix cycle.
In many cases these are patches for a bug, in which case bugzilla is a good place to stash an updated patch version to be looked over. (In a DVCS workflow this might be a branch on a fork rather than a flat patch, but the principle is the same and we *ought* to be able to do ok with patches -- 20+ years of free/open source devs have reviewed, iterated, and landed or clearly rejected changes this way, including us!)
Sometimes the only way people can get their code reviewed is to commit it. This is an old practice. Not to beat a dead horse, but this is all related to the same "patches sit unreviewed" issue, etc.
I find that reverting and yelling at people for broken commits is *not* a sustainable practice, even if it's old.
We need to show that we can hold up our end of the bargain: give timely feedback, keep up with both commits already done and with patches coming in through other channels.
It's a process, and we're all still feeling our way along.
Part of that is improving reviewer responsiveness to commits after they come in. Part is improving responsiveness to uncommitted patches.
And part of it is making sure that we send people and code through the review paths that will best fit them.
-- brion
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l