On Thu, 26 Feb 2004, Ernest L. Williams Jr. wrote:
I disagree, and I oppose the idea of having an additional intermediate tree. It would do nothing really beneficial, would make the latest software that now goes into rawhide, remain untested for LONGER, and thus remain buggy longer. It also would put an additional burden upon developers to have to track another tree, and to manually move packages from the "unstable" to the "not quite as unstable" tree from time to time.
Should this not be just another CVS branch for the test release.
No, it should not. CVS is linear. Branching is a very costly thing, and is avoided if at all possible. For example, XFree86 4.3.0-60 is the current XFree86 rpm. That single src.rpm package is the exact same package that would be released for erratum for Fedora Core 1, RHEL 3, RHL9 should the need arise. The specfile conditionalizes anything that is added that is experimental, so it only builds for rawhide. This way a single src.rpm is kept for all releases, and maintenance costs are dramatically reduced. The alternative, would be maintaining a separate src.rpm for each OS release, and then either porting/merging all important fixes across to 3 other releases, or else leaving the previous OS releases locked in stone, and only receiving mission critical bug fixes and security fixes.
Other packages follow a similar convention, based on what is best for the developer of the package and how it is maintained. Other packages might benefit more from having separate branches instead. One size does not fit all of course.
Then bugs should be filed against it. Updates should be placed in an updates repository so that testers get updates. The testers should not have to go to rawhide for a "released test", right. You have the technology to push updates to the rawhide repository as well as a Fedora 2 Test 1 Repository.
Rawhide *is* the updates repository. What is in rawhide *IS* what will be in the final OS. Having beta testers testing something else that is older and is NOT going to be in the final OS, is NOT beneficial. Rawhide is _always_ the current bits which will go on to become the final OS, and any testing someone does to a package older than rawhide is not very useful if a newer package is in rawhide. Of course, if both packages work great, then there is no problem. But if you're testing an older version of "foo" than the "foo" that is in rawhide, and reporting bugs found in it, and we've fixed them already and shoved it in rawhide, then your bug reports are just wasting developer time to say "we fixed that in rawhide, please upgrade".
Where is all of this difficulty coming from? Isn't this basic software development practices.
The only difficulty I see, is people not understanding that what is in rawhide _is_ what will become the final OS, and if they do not test it and it contains bugs, those bugs _will_ be in the final OS unless someone else does.
So, testers should be either:
1) Upgrading to the latest rawhide package if they find a bug, and seeing if it is fixed in the rawhide package first before reporting the bug to us. Then if the bug already exists in the latest rawhide package, querying bugzilla to see if someone might have already reported it, and adding themselves to the CC. Or reporting it in bugzilla if nobody has already - after testing the latest rawhide (preferably).
or
2) Fearing the risk of upgrading might damage something irreparably, the tester should stop testing that package until they feel that some newer rawhide package is safe enough for them to test.
or
3) Decide that this beta testing business is to risky for them and decide to wait until the final release instead, because they want a stable OS and can't risk nasty bugs or data loss. Nobody should ever run any beta or test release on a production system ever.