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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
