On Wed, Jun 1, 2011 at 8:23 AM, Roan Kattouw <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
