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.