rawhide stability

[Jeff Spaleta]

On 1/17/06, Erwin Rol <mailinglists at erwinrol.com> wrote:
> Before somebody points out that rawhide is a "play ground", I know, but
> at the moment I am just a bit frustrated with it because for me less and
> less things work with rawhide :-/

Your frustration is the result of your expectation that the
"stability" of rawhide is suppose to monotonically increase. Shed that
expectation and your frustration level will go down. No where has it
been stated that Test2 releases are devoid of "newness" and I think
historically test2 releases have seen a fair share of interesting new
brokenness especially at the day to day usage level compared to test1.

And I think i need to stress that the gnome issues you experience are
in part the result of tracking upstream gnome development. If Fedora
users want to see Fedora Core ship with the latest gnome desktop
release, then Fedora Core testing must track the unstable gnome
development tree in order to get upstream issues addressed before
gnome 2.14 is launched.

Fedora developers has to make a choice pretty early on to either test
the currently available "stable" gnome release or to track the
upstream gnome development process so that Fedora will have the
lastest "stable" gnome release when Fedora Core gets out of testing. 
If Fedora was not including the gnome 2.13 development components in
testing, then Fedora would be shipping gnome 2.12 after gnome 2.14 is
released. If fc5 shipped gnome 2.12 it would be extremely unlikely
that gnome 2.14 would ever show up as an update to fc5.  If the
dedicated testing process leading upto fc5 cannot shake out the bugs
in the gnome 2.13 codebase before gnome 2.14 launches, there is no way
in hell that gnome 2.14 would see enough fedora-centric testing to
ever be an update.

And as a gnome user, I'd much rather feel the pain of testing an
unstable gnome 2.13 as part of Fore Core testing, regardless of the
regressions in  the middle of the process, than to see Fedora Core
ship with an "old" gnome desktop instead of the currently available
gnome desktop when FC5 reaches public release.

I will say that in an effort to calibrate tester expectations a bit
better might be appropriate to prevent new testers from getting unduly
frustrated at the process.  Providing more hints in the schedule,
beyond communicating string change deadlines, as to the focus for each
test release would be one way.  It might be appropriate to have
subprojects have their own related schedules tied to the master test
release schedule. Would it help selinux developers and those
interested in testing selinux policy communicate if there were a
roadmap of selinux goals for each test release?

-jef