I think that Robert Day's initial point is correct. If there is no stable baseline then testers are constantly finding superficial bugs; deep bugs that take hours of testing will never get reached. Alan Cox is also right when he states that a tester should check against the current state of rawhide before he reports a bug.

> I think that Robert Day's initial point is correct. If there is no > stable baseline then testers are constantly finding superficial bugs; > deep bugs that take hours of testing will never get reached. Alan Cox is > also right when he states that a tester should check against the current > state of rawhide before he reports a bug. the more i read posted on this, the more i'm coming to sort of understand the other positions so, yes, i'm starting to understand the philosophy of, this early in the release process, just drive all of the changes out there and see what breaks.

but i guess it means that, unlike previous test releases from red hat, these early test releases really are unusable as *anything* but test platforms.

as i mentioned in a previous post, it used to be that ambitious testers would just flat out install the test release, knowing that it would have problems, but they'd be prepared to deal with that, *knowing* that as bugs were reported and patches issued, their systems would slowly get more and more stable, and their lives would return to normal. well, as normal as testers' lives get.

but with this new fedora approach, that's just not true anymore, at least for the first release or two. if one is constantly updating against rawhide, then you have to assume that, as some things get fixed, others will get broken. which makes it pretty much impossible to use such a system for useful work, no? not a complaint, just an observation. :-)

based on what i read, it's only toward the very end of the entire testing cycle (FC2-test3) that feature freezes start to kick in and we should see things returning to normal in preparation for the official release.

However, is there not a Fedora 2 Test-l updates tree?

yum fedore-core-2-test1-updates \ http://fedora.redhat.com/updates/released/fedora-core-1

> >> I think that Robert Day's initial point is correct. If there is no > >> stable baseline then testers are constantly finding superficial bugs; > >> deep bugs that take hours of testing will never get reached. Alan Cox is > >> also right when he states that a tester should check against the current > >> state of rawhide before he reports a bug. > > > >the more i read posted on this, the more i'm coming to sort of > >understand the other positions so, yes, i'm starting to > >understand the philosophy of, this early in the release process, > >just drive all of the changes out there and see what breaks. > > That's how it has been for 10 years. I'm not sure why some > people think the processes that have been used all this time are > all of a sudden bad. Perhaps people just do not understand the > procedures and what to expect. That is true. However, is there not a Fedora 2 Test-l updates tree? IF there is then Testers should use that, right??

however, the rate of package updates via rawhide has been rather overwhelming and makes me wonder at the value and efficiency of testing such a fast-moving target. I realize it would be more work, but perhaps an approach with multiple stability levels like FC1 (updates, testing) or ATrpms (at-stable, at-good, at-testing, at-bleeding) repository hierarchy (probably with fewer levels) would provide an opportunity for better in-depth testing of some of the more stable packages in a somewhat more stable environment, while allowing the real bleeding edge fans to drink from the rawhide fire-hose.

On Fri, 2004-02-27 at 09:31 -0500, Phil Schaffner wrote: > however, the rate of package updates via rawhide has been rather > overwhelming and makes me wonder at the value and efficiency of testing > such a fast-moving target. I realize it would be more work, but perhaps > an approach with multiple stability levels like FC1 (updates, testing) > or ATrpms (at-stable, at-good, at-testing, at-bleeding) repository > hierarchy (probably with fewer levels) would provide an opportunity for > better in-depth testing of some of the more stable packages in a > somewhat more stable environment, while allowing the real bleeding edge > fans to drink from the rawhide fire-hose. > I agree with Mike and Jef; Jef Spaleta wrote: In my opinion, the biggest bottleneck is utilization of developer time...developer time is the scarce resource. Building a testing process thats most convenient for the testers but puts an undue burden on the developers isn't a process based on the realities of the resource economics involved. Mike A. Harris wrote: *EXACTLY!* Someone *GETS* it. I want fast moving improvements and fixes. Packages are tested by the developer before going to rawhide for testing. If this moves to fast for you then get off the rawhide channel but don't slow everyone down. Doing as you suggest would severely cripple the testing/bug reporting/ fixing process by adding more internal loops.

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.

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.

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.

On Fri, 2004-02-27 at 19:18 -0800, Sean Earp wrote: >Hello All- > >With Evolution 1.5.3 (the latest version installed on FC2 Test 1), no >HTTP Links (in an email) work for me. They do not open a browser, they >do not generate an error message, they do not do anything at all. >Email links work just fine. Could someone let me know if their copy of >Evolution is experiencing the same problem and I'll throw it at >Bugzilla. Thanks, > > Try installing epiphany; yum install epiphany

Is there anything that can be done to change this silly requirement? Am I missing anything? Any information/suggestions/flames/thoughts would be much appreciated. Thanks,

On Mon, 2004-03-15 at 00:44, Tom 'spot' Callaway wrote: >On Sun, 2004-03-14 at 21:07 -0800, Sean Earp wrote: > > >>Is there anything that can be done to >>change this silly requirement? Am I missing anything? Any >>information/suggestions/flames/thoughts would be much appreciated. Thanks, >> >> >I've never had this problem, Evolution 1.5.* has always obeyed the >browser preference I set with gnome-default-applications-properties >(galeon, in my case). > >

>Default is epiphany ... but isn't installed by default :) > >

hat would be one for bugzilla

Ah did I misunderstand you -

I thought this was also true of 1.4.5/6 from your earlier email.

Test Release - is it merely a convenient snapshot for installation but serving no useful purpose after that (other than PR)? This is what I would gather from those that advocate that testers stay in sync with Rawhide.

Rawhide - is it the staging ground for release candidates or is it a communication point between a developer and those that are in contact with him? If it is the latter, then there needs to be another repository that indicates that a package is ready for global testing. If it is the former, than I wonder why an intermediate stage exists in the Core 1 tree.

I think that Robert Day's initial point is correct. If there is no stable baseline then testers are constantly finding superficial bugs; deep bugs that take hours of testing will never get reached. Alan Cox is also right when he states that a tester should check against the current state of rawhide before he reports a bug.

I think that a lot of the confusion comes form a lack of a public test plan and the lack of guidelines for testers. Also, for some reason, the difference between internal testing (which in the framework of open source I would consider them to be dedicated testers) and beta testers (those trying to use the features in a real environment) has been totally blurred. Most of the arguments against Robert Day were from the perspective of internal testers. They are right for their function. But most of them didn't need Test 1 except to test Anaconda; they were in sync with rawhide anyway. For beta testers, a stable platform is needed. If they are not at least pretending to do useful work then real life considerations will never be actualized.

In summary, I also advocate an intermediate repository whose sole purpose is to keep the baseline usable.

If Redhat is unwilling to do this until development branches to Core 3, then I must assume that Redhat regards final release of Fedora as the real beta.

On Tue, 24 Feb 2004, shmuel siegel wrote: >Test Release - is it merely a convenient snapshot for installation but >serving no useful purpose after that (other than PR)? This is what I >would gather from those that advocate that testers stay in sync with >Rawhide. Test release of an OS snapshot, ie: "Fedora Core 2 test 1", is essentially a prebeta snapshot of the OS, which is very likely to be unstable. In the past, there were private beta testers and approximately 3 "alpha" releases that were generally not ready for public consumption, but needed wider testing than could be done internally. With the opening up of OS development, and creation of the Fedora Project, it was decided to make _all_ of the beta/alpha/whatever you want to call it releases public and open. The upside is that there would be more testers this way. The downside, is that people who voluntarily test the first few initial test releases without realizing that they are playing with fire, are likely to end up with very broken systems, as "test1" is a very first test, and is nowhere near "stable". The warnings in the installer should not be taken lightly. >Rawhide - is it the staging ground for release candidates or is it a >communication point between a developer and those that are in contact >with him? If it is the latter, then there needs to be another repository >that indicates that a package is ready for global testing. If it is the >former, than I wonder why an intermediate stage exists in the Core 1 >tree. Rawhide is the current set of packages that were built internally. The rough process, is this: - Developer updates a package to a newer version, or fixes some bugs, adds patches, whatever. - Developer builds package locally on his workstation and does whatever testing he deems necessary. - Developer submits package into the buildsystem, telling it to build the package into the Fedora Core 2 development tree. - Once the package has been successfully built on all 7 architectures, the buildsystem accepts the package into the internal Fedora Core 2 development tree. The above process is how we update all of our packages during development essentially. So what is rawhide then? Simple. Once every day or so, a script is ran either automated or manually, which takes all of the latest src.rpm and binary rpms in the current internal Fedora Core development tree, and mirrors them to our ftp staging server. The staging server then pushes the rpms to the public ftp servers. This is called "rawhide". There is zero QA testing done on any of the rawhide packages, because they are not "production ready", they are "work in progress, fresh off the press, caveat emptor, beware of large dog" or as Jef Spaleta puts it "rawhide might kill babies". Do not use rawhide if you can not accept the possibility of total system meltdown and data destruction. While it does not occur very often, it _CAN_ occur, and it does from time to time. ;o) How does rawhide differ from "test1" or other test releases? Again, that's a simple question with a simple answer. A 'test' release, or beta, or whatever you want to call it, is a snapshot in time of rawhide. Essentially, rawhide is snapshotted, and then ISO's are built, and some testing occurs with them. Any major problems that pop up, we try to fix in hopes that it will be as installable as possible for as many people as possible, without delaying the test release unnecessarily. In other words, a "test" release is unstable rawhide which might burn your house down, only very slightly better. Packages continue to build into our internal development tree after that, which will continue to be mirrored to rawhide daily or so, and will go on eventually to become "test2", etc. Eventually after all test/beta/release candidates, etc. are done, we work up towards the final "gold" OS release which would be "Fedora Core 2". That's it in a nutshell, excluding the finer details. >I think that Robert Day's initial point is correct. If there is no >stable baseline then testers are constantly finding superficial bugs; >deep bugs that take hours of testing will never get reached. Alan Cox is >also right when he states that a tester should check against the current >state of rawhide before he reports a bug. By definition, "in development" *means* "there is no stable baseline". >I think that a lot of the confusion comes form a lack of a >public test plan and the lack of guidelines for testers. Also, >for some reason, the difference between internal testing (which >in the framework of open source I would consider them to be >dedicated testers) and beta testers (those trying to use the >features in a real environment) has been totally blurred. Most >of the arguments against Robert Day were from the perspective of >internal testers. They are right for their function. But most of >them didn't need Test 1 except to test Anaconda; they were in >sync with rawhide anyway. For beta testers, a stable platform is >needed. If they are not at least pretending to do useful work >then real life considerations will never be actualized. If people require a stable platform, they definitely should not be using rawhide at all, and should not be using any test release. The entire purpose of the test releases, is that they *are not* stable, and we need people willing to test them anyway, and to report the instabilities to us, so that those instabilities _can_ be fixed. If nobody ever wants to test anything except "stable" packages, then unstable packages wont get tested, wont get fixed, and the final OS wont be stable either. >In summary, I also advocate an intermediate repository whose >sole purpose is to keep the baseline usable. 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.

>If Redhat is unwilling to do this until development branches to >Core 3, then I must assume that Redhat regards final release of >Fedora as the real beta. Feel free to have that opinion if you wish, just note that your opinion is not shared by everyone, and is just that - one opinion. Others will both agree with you, and disagree with you. I disagree. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

Rawhide *is* the updates repository. What is in rawhide *IS* what will be in the final OS.

A good way to look at it is like this. Development of a Fedora release may look something like this: ^^^^^^^^^^^^/\^^^^^^^^^^/\^^^^^^^^^^^^/\ Each ^ is a rawhide release. Each /\ is a test release. You see, they are all the same product, the thing is that each rawhide release is a fix or a change, released to interested persons RIGHT THEN. This is most often nearly untested code. Its all part of the process to the same product, not a separate product or any such thing. Rawhide is just a way for you to get the VERY latest in what the developers are working with for the next release version.

i understand now that, by definition, rawhide represents the current state of the test, and that *everything* in rawhide is theoretically going to be included in the next release. so far, so good. but is there any way now that the fedora folks can offer up some package or newer release of a package that they'd like to offer for testing, but is simply too new/untested to be included even in rawhide?

> Its all part of the process to the same product, not a separate product > or any such thing. Rawhide is just a way for you to get the VERY latest > in what the developers are working with for the next release version. hang on a sec, there was one point i was trying to clarify in my previous post. (i'm not trying to be difficult; i am merely succeeding.) i understand now that, by definition, rawhide represents the current state of the test, and that *everything* in rawhide is theoretically going to be included in the next release. so far, so good. but is there any way now that the fedora folks can offer up some package or newer release of a package that they'd like to offer for testing, but is simply too new/untested to be included even in rawhide?

in short, is there any mechanism/channel to provide packages that the fedora folks would like to offer for testing, but are too far ahead of the curve, even by rawhide's standards? or is it the position that, if it doesn't belong in rawhide, we're not going to talk about it. i have no problem with that, i just wanted to make sure i understood.

On Fri, 27 Feb 2004, Mike A. Harris wrote: > Rawhide *is* the updates repository. What is in rawhide *IS* > what will be in the final OS.

does this mean that a package showing up in rawhide represents a *commitment* that it will be in the next release (be it test or official)?

surely, there must be the option that, if such a package represents a complete disaster, RH will back off and revert back to an older, working release, no?

but if the newer version was already in rawhide for a while, folks will undoubtedly have downloaded it and begun testing it, and because of the update process, they're stuck with that newer version until the next snapshot. is that about right? does this have any sub-optimal consequences? just curious.

1) the proposed next release, and 2) the source of really cool, new, bleeding edge stuff

put another way, is rawhide ever allowed to get ahead of what's planned for the next release?

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.

On Thu, 26 Feb 2004, Mike A. Harris wrote:

does it make sense to suggest that, in terms of stability, what used to be the first beta release might be equivalent to something like a -test2 these days? not a criticism, just an observation, since it gives me a much better idea of what i should be doing in terms of testing.