Tyler wrote:
> 1. Fix the extension quickly
> 2. Revert the change
> 3. Undeploy the extension until its fixed to be compatible with core
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.
I think you're setting up a false premise.
Based on the timing description here, it seems more like "Either rush 1 or
rush 2".
One of these is going back to a known state, albeit with a known bug. The
other is going forwards to an unknown state.
As the grumpy cat cartoon going around recently points out, our code had 99
bugs in it, we patched one, and now we have 127 bugs in it. Rushing new,
untested patches forwards under deadlines starts to approach the "real
world people get fired for this" behavior from earlier comments.
Rolling back lets you work out what the right thing to do is for next week,
without (much) time pressure. If the pre-existing bug was tolerable enough
to have been there for a while without requiring an emergency prod patch,
it can stay another week without disaster striking.
On Thu, Mar 6, 2014 at 6:58 PM, Tyler Romeo <tylerromeo(a)gmail.com> wrote:
> 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
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
-george william herbert
george.herbert(a)gmail.com