On Thu, Mar 6, 2014 at 9:21 PM, Jon Robson <jdlrobson(a)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:
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