On Thu, Mar 6, 2014 at 9:21 PM, Jon Robson <[email protected]> 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: > 1. Fix the extension quickly > 2. Revert the change > 3. 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
