Testing test releases: do not update

Mike A. Harris mharris at redhat.com
Fri Feb 27 06:39:03 UTC 2004


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





More information about the fedora-test-list mailing list