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.
--
Mike A. Harris
ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat