rawhide stability

[Jeff Spaleta]

On 1/17/06, Erwin Rol <mailinglists at erwinrol.com> wrote:
> The thing I am a bit afraid of is that rawhide will end up being a "2.5
> kernel". Because people hear it is so unstable and breaks a lot, many
> people will probably just wait for a RC release before really testing
> it.

I'm pretty sure there aren't widely available "RC releases" for
fedora. You either jump in during the testing or you hold your breath
and wait. Anyone waiting for later test releases, are simply asking
for whatever problems they might be in a position to provide special
information on to go unfixed.  What you describe is a catch-22
situation. If there were no problems, then testing wouldn't need to
happen. But if there are problems, then people are reluctant to test. 
 Your concern speaks to the heart of the underlying problems with
expectations.  Following your example, I think the kernel's new
development cycle shows exactly how developers are going to force
people to re-calibrate their expectations.  Kernel development is much
more aggressive now in the 2.6 tree. There is no 2.7 kernel tree.. new
features are now going into 2.6 minor revisions which prevents people
from sitting on the fence waiting for the tree to stablize without
getting invovled. Regressions between 2.6 minor versions happen with
some frequency because of the change to the aggressive development
model and are caught more quickly because users of the vanilla tree
have no way to avoid running into them.

Fedora's development model is also very aggressive. New things are
going to go in through a large chunk of the test phase... thats been
the reality.. and it will continue to be the reality. Fedora's
development is aggressive.  The only problem Fedora may have a lack of
communication as to exactly how aggressive development is and some
communication as to subsystem development goals for each test release.
No one should expect test2 to be "more stable" across the whole
distribution from an end-user standpoint. The expectation should be
broken crap in test2 should have a small overlap with broken crap in
test1. And that the broken/new crap in test2 should be higher up in
the software stack than in test1 if at all possible.

Bugs are either going to be found now in the testing phase or later in
the final release. Anyone in the fedora community with the skills,
time and the hardware available to be a part of the testing process
that chooses to take a wait and see approach are gambling with their
own final release experience.  I'm certaintly not going to be very
sympathetic to anyone who decided against participating in the testing
process because there were too many bugs, and just sat on their hands
hoping fc5 would get better without their help.

> Maybe massive updates like the gcc and gnome stuff should happen in a
> bit more controlled manner. For example more warnings to the testers
> that something big is going in.

Uhm... where have you been? I've seen more than enough fair warning.
The decision to move to the gnome 2.13 tree happened pretty early. 
And there was most certaintly a heads up in the lists concerning the
gcc shift. Hell... test2 got pushed back by weeks because of the gcc
shift.. i don't know how you could have been more warned about what
the shift in gcc means.  I don't see how more explict warnings
concerning these specific things would have helped... and I really
don't see how you can get more "controlled" with regard to either. 
The underlying problem is expectation mismatch.

> I don't know if it is technically possible, but maybe some easy way to
> rollback rpm's in yum would be useful.
rollbacks are ill-defined in rpm. Many of the rpm packaging mechanisms
are not constructed with "rollbacks" i mind..
triggers..conflicts..obsoletes.. these packaging concepts assume
"updating" and are seldom tested for correct behavior for any
definition of "rollback". This isn't a job for yum to try to figure
out.

As a tester, you can choose to keep a all the updates you download in
local cache and you can do rpm -Uh --oldpackage  on individual sets of
packages and you deem necessary. But be warned, downgrading is not
well tested from an rpm standpoint and you could very well end up with
unexpected problems in the --oldpackage effort.  And if you ever do a
yum clean all and wipe out your local cache of downloaded
updates..well..you'll have to ask around and see if another tester has
the package you need cached.