On Mon, 2004-03-01 at 11:56 +0100, Axel Thimm wrote: ..snip..
Another question raised is suitability of rawhide for wider testing, e.g. a better stability handling. One would have to think about offering stability segmentations in rawhide (something like rawhide-testing vs rawhide-experimental, new/updated packages entering the latter and being moved to the former after some given time). No waste of resources other than the initial setup, and could offer benefits, as more users would be willing to track the time-delayed and somewhat tested rawhide-testing repo.
I think that a lot of the problems that I see from the testers POV on rawhide stem from;
1. Not getting a clean update to rawhide from FC1 (not recommended). 2. The slow default rawhide repo. 3. The stability of up2date/yum. 4. The pure volume of rawhide updates. 5. The non-syncing of the development mirrors.
I don't think the main problem is rawhide package stability. In general I've found rawhide packages more stable than the original test1 release.
I think that a lot of the problems from a developers POV is duplicate/ bad bug reporting and time management. More testers doesn't necessary translate into better testing.
I'd prefer these issues be attacked head-on first. Unfortunately, you'll never fix the volume issue. Sometimes many packages need to be rebuilt only because of a dependency update, like a gcc update. And many times these large rebuilds can affect overlapping packages. I really don't see moving a package from one segment to another without a rebuild as all that common. Maybe I'm wrong but it seems like stability segmentation of rawhide would be lead to having another development channel. A tanned-hide? And the big question is does this really hurt or help the developer? My thinking is attack the present known problems head-on first and give some more time for things to sort out.
I don't think we disagree. I think we both want the developers needs put first and foremost so that we get to FC2 gold as fast as possible.