On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
But the problem is what to do if the testing ALREADY failed. Then the
best
strategy is to fix the problem ASAP, bypassing testing this time, to get the
regression out of the way.
So testing failed, ergo the best way to fix it is to bypass the testing
all together? Really? If you failed that badly the first time, there
should be lots of people lined up to make sure you don't fail the second
time. You should be able to get positive karma votes within a few hours
of the bodhi update being filed, which should be plenty of time before
the next updates push.
>> why should our users have to suffer through them for several days
>> instead of getting them fixed in the next update push (i.e. as soon as
>> possible)?
>
> This is a logically callow statement. Our users do not *suffer* from
> non-critical updates being delayed for a short time,
An update fixing a regression from the previous update is not really "non-
critical". Users will definitely suffer if their package is broken when it
used to work. The sooner you fix it, the better.
> nor do they *suffer* from critical updates getting sufficient testing
Most users are not going to manually pull updates from testing, nor to use
testing wholesale. So they WILL suffer the effects of the bug for a longer
time if the update is being held in testing rather than pushed to stable.
> so as not to immediately require *another* critical update.
The point is to do direct stable pushes only where this is very unlikely
(e.g. because the fix for the regression is a one-line or otherwise trivial
fix). I know the likelihood can never be 0, but if you can choose between a
likelihood of .001% of the package being broken (due to another, unforeseen
regression) or a likelihood of 100% of the package being broken (because the
regression fix is not in stable yet), why choose the 100%? In the worst case
you push another update directly to stable to fix the second regression, but
the chance of this being necessary is extremely low.
> At no point in the scenario you paint is there any actual suffering.
Sorry, but a user sitting in front of a broken application definitely
qualifies as "suffering" under my definition.
> You haven't actually demonstrated any real problems it will introduce;
> just the same (rather thin) strawman over and over.
I have, you keep either ignoring or failing to understand my arguments!
(There is even more than one, but regression fixes are something I care
particularly about, I feel very strongly that direct stable pushes are often
the best approach for those.)
> Given a lack of actual, real problems demonstrated with the bizarro
> concept of actually requiring that updates go through our QA
> infrastructure, the answer certainly seems to be: yes, absolutely.
Actual, real problem:
* update X gets created
* update X sits in testing for 1 or 2 weeks, either no regressions are found
or all those that are found get fixed
* due to the positive feedback, update X gets pushed to stable
* within a day of the stable push, a regression is found in update X (as by
design, many more people run stable than testing)
* update X' gets created to fix the regression in update X
Now we have 2 options:
a) let X' sit in testing for a week. Users are affected by the regression in
X for a full week.
b) push X' directly to stable. Users are only affected by the regression for
the time it takes to process the push containing X', which is the minimum
possible response time.
How is option b not more desirable than option a?
Strawman. You've completely missed option c. Submit update to bodhi,
get a few people to test the update direct from bodhi links (hey look,
bugzilla has those links!) and provide karma feedback. Update gets to
skip updates-testing and go directly to stable, due to karma feedback.
And this is NOT a fictive example, it has happened many times with real
updates.
Option C isn't fictive either, it happens many times with real updates.
So yeah, you can create a strawman where you are handcuffed to somebody,
and you decide between chopping your hand off vs chopping their hand
off. Makes chopping their hand off look like the best option, only if
you ignore the key to the handcuffs sitting on the counter.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca:
http://identi.ca/jkeating