On Thu, Mar 6, 2014 at 9:21 PM, Jon Robson jdlrobson@gmail.com wrote:
I wonder in future if it might be practical useful for test failures like this to automatically revert changes that made them or at least submit patches to revert them.... that way it's clear how and when things should be reverted.
Or, at the very least, changes are not deployed until these tests pass. I agree that running expensive browser tests on every Gerrit change is unnecessary and performance-intensive, but we can expect it to be OK to run it before new deploys.
Rob said:
I wholeheartedly disagree with this. Changes to core should definitely take into account uses by widely-deployed extensions (where "widely-deployed" can either mean by installation count or by end-user count), even if the usage is "incorrect". We need to handle these things on a case by case basis, but in general, *all* of the following are options when a core change introduces an unintentional extension incompatibility:
- Fix the extension quickly
- Revert the change
- Undeploy the extension until its fixed to be compatible with core
I don't think you see the problem here. Consider this case as an example (I agree that this is case-by-case, so let's limit the scope to this one). You're forgetting that the original patch fixes a bug. In fact, it fixes a pretty serious UX bug in my opinion (and many others who supported merging this patch).
So to summarize, #3 is obviously not an option. For #2, are we supposed to block core development, and let this bug persist indefinitely, because of a much less serious bug in an extension? That really only leaves #1, but apparently the vast minority of opponents of the original patch decided it was a good idea to jump right over and skip to #2.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science