On 1/17/06, Erwin Rol <mailinglists@xxxxxxxxxxxx> 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
