On Wed, Jun 1, 2011 at 8:23 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
This, for me, is the remaining problem with the 72-hour rule. If I happen to commit a SecurePoll change during a hackathon in Europe just as Tim leaves for the airport to go home, it's pretty much guaranteed that he won't be able to look at my commit within 72 hours. Or maybe I'm committing an UploadWizard change just after 5pm PDT on Friday, and the next Monday is a federal holiday like the 4th of July. Or maybe the one reviewer for a piece of code has just gone on vacation for a week and we're all screwed.
I think rather than us being all screwed, this is a situation where we *don't actually have to* commit that change to trunk right at that exact time. Unless the change needs to be deployed immediately -- in which case you really should have someone else looking it over to review it IMMEDIATELY -- it can probably wait until reviewers are available.
And if it does get reverted before the reviewer gets to it -- what's wrong with that? It'll get reviewed and go back in later.
Part of the reason we went so hog-wild with handing out commit access for a long time is because we've never *been* as good as we want about following up with patches submitting through the bug trackers and mailing lists; sometimes things get reviewed and pushed through, but often they just get forgotten. Letting people commit directly meant that things didn't get forgotten -- they were right there in the code now -- with the caveat that if there turned out to be problems, we would have to go through and take them back out.
It's a trade-off we chose to make at the time, and it's a trade-off we can revisit if we change the underlying conditions.
-- brion