QA's Package update policy proposal

[Al Dunsmuir]

On Tuesday, March 9, 2010, 8:09:40 PM, Kevin Kofler wrote:

>> Jesse Keating wrote:
>> On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote:
>>> It seems to cast doubt on the value of karma -- just because something
>>> gets lots of positive karma on N doesn't mean that N-1 is ok.  Then
>>> again, the same concern is present in any grouped update if the voters
>>> haven't tried *all* of the packages mentioned.
>> 
>> Even if you put an update for N and N-1 in the same form, once you
>> submit the request it splits it into two requests, one per Fedora
>> release.  This means you'd have one set of karma per Fedora release.

> Indeed, and I'd argue that this is a problem, not a feature. If an update is
> confirmed to fix an issue in the current stable release and the previous
> stable release is affected by the exact same issue, I don't see a good
> reason not to push the update with identical changes to the previous stable
> release as well. Not doing it would result in the previous stable release
> not getting bugfixes in a timely manner, if at all, anymore, as it has a lot
> fewer testers.
>         Kevin Kofler

Just  to  be  clear,  I  am  in the "adventurous user" camp that would
prefer  to have the bug fix retrofitted to the older release. I would,
however, qualify that as follows:

The  update to an older stable release should be made widely available
in   that   release's   updates-testing   after  the  equivalent  (not
necessarily identical) fix has been widely tested in the latest stable
release. To me, this means separately developer unit tested, tested by
users  in  updates-testing and then for several weeks of real user use
in stable.

In  parallel  with  that, separate developer unit testing of the older
release   should   be   done,   with   entry   to  the  older  release
updates-testing  only  after  the  original fix has been proven in the
latest stable release.

This minimizes the risk that due to a different execution environment,
build  environment, configuration or whatever the seemingly equivalent
fix  does  not work but causes a regression. You may start at the same
place  in  the  older stable release, but may end up down and entirely
different rabbit hole.

Firing off the "same" fix for multiple targets other than rawhide and
the latest release makes me nervous.

So  to  summarize,  fixes  in multiple releases yes, but with separate
schedules for build and testing.
Al