On Thu, Jul 16, 2015 at 10:08 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
That last one is actually an area where I *dis*agree with the FreeBSD guidelines - I see asking for someone to revert a change as a big deal, as it means we're laying claim to a non-trivial amount of their time. A non-urgent request for clarification is a different story, but I also see us occasionally repeating a pattern where long before the person that actually made a change has a chance to respond to a thread, there'll be half a dozen or more people jumping in saying "Yeah, I want an answer too!".
I have seen a couple of these too. Sometimes it is a pile on, but other times it is a very reasonable question to python-dev that goes completely unanswered. Those cases (which are admittedly few) are unfortunate b/c if one person has a question about a commit, then others probably to do. When the question goes unanswered, then we miss out on learning something.
For example, I remember a case from a few months ago where someone (don't remember who off the top of my head) made a micro-optimization and there were post-commit questions about it. As far as I can tell, the question went unanswered and I sincerely was curious what the rationale for the change was. I felt like there was something we all could have learned from the potential discussion around the question that was asked.
Given the global nature of the lists, I think we should be giving folks *at least* 24 hours to reply to a question before assuming they're not going to respond, and given that only some of us get to count reading and replying to python-dev threads as work time, a few days leeway would be better (perhaps even a week to account for folks that are busy with other things during the week and mostly contribute on weekends). Those of us that *do* get paid for this also need to try to remember to account for that asymmetry in available time for participation.
To me this depends on why the change is being questioned. If there is a question about why a change was made or a minor bug was found in post-commit review*, then I agree it can wait a few days. On the other hand, if someone commits a change that turns all the build-bots red and doesn't respond for several hours, then I would think that is fair game to revert.
So, I do think reverting changes is a very reasonable course of action at times. It should just be used judiciously.
-- Meador
- Ideally these kinds of things would be caught in pre-commit review, but I understand that it is not always practical to expect that everyone gets a chance for pre-commit review for every change or that every bug is caught in pre-commit review.