rawhide stability

[Erwin Rol]

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. Just like the 2.5 kernel that nobody wanted to use, until Linus
called it 2.6. If that happens rawhide will get less and less testing,
and so the RC releases get more and more left over bugs. And that can't
be good for anybody. 

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. 

I don't know if it is technically possible, but maybe some easy way to
rollback rpm's in yum would be useful. For example make snapshot with
"yum snapshot <name>", than install new stuff with "yum update" or "yum
install", if you than notice everything/something broke, use "yum
rollback <name>". That way it would be easier to undo some broken
updates and wait for the next update.  

- Erwin


On Tue, 2006-01-17 at 09:44 -0500, Jeff Spaleta wrote:
> 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
>