On Fri, Feb 27, 2004 at 10:57:04PM -0500, Sandy Pond wrote:
On Sat, 2004-02-28 at 01:56 +0100, Axel Thimm wrote:
On Fri, Feb 27, 2004 at 10:15:34AM -0500, Sandy Pond wrote:
Doing as you suggest would severely cripple the testing/bug reporting/ fixing process by adding more internal loops.
You mean tagging packages as stable or less stable? I haven't experienced slowing down or waste of developer time with stability classification, on the contrary. Users can tune their system to their liking and I can push out packages faster. Much like the new testing updates FC1 introduced.
I do very much appreciate your contributions as well as the other third party repos. But Redhat already has three levels in FC1.
I see base packages as "shipped" on the release day and updates as the same stability class. updates/testing is the new stability class.
The FC2 test1 snapshot is somewhat stable, as probably the FC2 test2 snapshot will be. Now some people want to add more development loops to the development channel.
rawhide/development is just fine as it is, and test releases should not have updates. While currently there are statements that say updates for test releases are found in rawhide/development, this is a rephrasing of "No updates for test releases, but you can jump onto rawhide, while it is still timely close to the test release".
IMO bug reports and discussion about non-updated test releases belong to "test" and such of "updated test releases, aka rawhide" belong to "devel" entities (which is what I wanted to say at the beginning of this thread and was partly misinterpreted as a request for update channels for test releases).
It's perfectly alright for the development model. Test releases are rawhide snapshots which have been stabilized more than the usual rawhide to allow for distribution and testing of a special development environment. That's all. There are benefits for the developing from both bug reports from non-updated test releases, as well as from rawhide trackers. If the ratio becomes bad to either direction, I guess there will be actions to make the other side of the scale more attractive.
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.
Currently I believe there isn't really a demand/need from the developers' POV for the above solution (and their POV is the important one for beta/devel stuff), but maybe in the future this may change and be reviewed if increasing the testing userbase becomes an issue.
I say let's leave it alone and reserve the development channel as a streamline for quickly pushing new packages, finding bugs and getting them fixed as quick as possible. Frankly, I'm finding rawhide much stabler than in the past when I've played with it.
I think if you need a stable machine use FC1 (Jeez ... I got one machine that still has RH8 on it that I got to get to) ... if you need a testing/development machine then use FC2.
Did we disagree? ;)