This thread has been beating around the bush and avoiding even an attempt to reach agreement. People need to first agree on the purpose of this testing and the definition of the resources. Even the original poster seems to have lost track of his original purpose for posting.
To try to put things in their perspective, I think the following terms need definition, both to what they are and their purpose.
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:
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.
does this sound about right?
rday
p.s. i'm still interested in a real tester's document some day.
p.p.s. and i'm still curious about what constitutes the "Fedora Core devel" version that's listed at bugzilla. if i'm running FC2-test1, and i'm regularly updating against rawhide, and i run into a bug, do i file it against "test1" or "devel"? what if i have no idea whether it was an original test1 package, or it was an upgrade from rawhide? or does "devel" mean something totally different?
p.p.p.s. can we just officially call it "rawhide" again? :-P
On Tuesday 24 February 2004 08:07 am, Robert P. J. Day wrote:
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.
but with this new fedora approach, that's just not true anymore, at least for the first release or two.
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.
This is new to the public; but the former private beta tests have always been like this. Typically, the first public beta was the third or fourth actual test release; the first two or three were for the private beta test team (that is now not so private). The big difference this go around is that you can actually attempt to update the test release.
On Tue, 24 Feb 2004, Robert P. J. Day wrote:
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.
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.
Ah, but in the past, the public only got to see beta release 4, 5, and 6. The first 2-3 betas that destroyed the universe, were not public, and so you did not see the level of breakage that occured in earlier betas. Now things are even more open, and people who elect to see the level of breakage in early betas, can now do so. Those who do not want to see high level of breakage, should really sit out a few test releases and wait for the OS to stabilize. Or should only test low-risk packages individually, and not make changes to their core OS that could break everything.
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.
In the past though, as indicated above, the initial betas weren't public, and so you never got to see just how broken things can get. ;o)
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. :-)
That's a fair observation, but you should be aware that this is absolutely no different than any previous OS release, other than the fact it is an open process now. We _NEED_ wider testing than we can do internally alone in order to get things in a more stable state. That either means we do private beta releases with a selected team of individuals who 100% accept the deal about the chances of having a totally broken system for the private betas, or we make it open, and let people decide for themselves. We chose the latter. One thing we can _NOT_ do, is guarantee the stability of the OS, when it is in early development, which is where things are today.
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.
On Thu, 2004-02-26 at 17:16, Mike A. Harris wrote:
On Tue, 24 Feb 2004, Robert P. J. Day wrote:
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??
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.
Ah, but in the past, the public only got to see beta release 4, 5, and 6. The first 2-3 betas that destroyed the universe, were not public, and so you did not see the level of breakage that occured in earlier betas. Now things are even more open, and people who elect to see the level of breakage in early betas, can now do so. Those who do not want to see high level of breakage, should really sit out a few test releases and wait for the OS to stabilize. Or should only test low-risk packages individually, and not make changes to their core OS that could break everything.
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.
In the past though, as indicated above, the initial betas weren't public, and so you never got to see just how broken things can get. ;o)
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. :-)
That's a fair observation, but you should be aware that this is absolutely no different than any previous OS release, other than the fact it is an open process now. We _NEED_ wider testing than we can do internally alone in order to get things in a more stable state. That either means we do private beta releases with a selected team of individuals who 100% accept the deal about the chances of having a totally broken system for the private betas, or we make it open, and let people decide for themselves. We chose the latter. One thing we can _NOT_ do, is guarantee the stability of the OS, when it is in early development, which is where things are today.
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.
On Thu, 2004-02-26 at 18:08, William Hooper wrote:
Ernest L. Williams Jr. said:
However, is there not a Fedora 2 Test-l updates tree?
The updates tree is Rawhide (aka development).
So, in "/etc/sysconfig/rhn/sources" What is the differences in the following repos?
=========================================================================== yum fedora-core-rawhide \ http://download.fedora.redhat.com/pub/fedora/linux/core/development/$ARCH/
yum fedore-core-2-test1-updates \ http://fedora.redhat.com/updates/released/fedora-core-1 ===========================================================================
You mean that both point to rawhide? Or maybe, my sources file is not correct.
-- William Hooper
On 26.02.2004 15:24, Ernest L. Williams Jr. wrote:
yum fedore-core-2-test1-updates \ http://fedora.redhat.com/updates/released/fedora-core-1
The above is an FC1 updates URL, not an FC2-test1!
On Thu, 2004-02-26 at 18:34, Aleksey Nogin wrote:
On 26.02.2004 15:24, Ernest L. Williams Jr. wrote:
yum fedore-core-2-test1-updates \ http://fedora.redhat.com/updates/released/fedora-core-1
The above is an FC1 updates URL, not an FC2-test1!
Okay, Thanks for the clarification.
-- Aleksey Nogin
Home Page: http://nogin.org/ E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907
On Thu, 26 Feb 2004, Ernest L. Williams Jr. wrote:
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??
rawhide is the updates tree for any and all test releases. All new packages go into rawhide always, which are newer than whatever the last released test release was. Testers should use rawhide, and only test packages that they are comfortable accepting the fact that the given package might be totally broken and unuseable and may even destroy data or damage the OS installation requiring a total reinstallation from scratch.
On Thu, 2004-02-26 at 17:16 -0500, Mike A. Harris wrote:
On Tue, 24 Feb 2004, Robert P. J. Day wrote:
snip<
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. :-)
That's a fair observation, but you should be aware that this is absolutely no different than any previous OS release, other than the fact it is an open process now. We _NEED_ wider testing than we can do internally alone in order to get things in a more stable state. That either means we do private beta releases with a selected team of individuals who 100% accept the deal about the chances of having a totally broken system for the private betas, or we make it open, and let people decide for themselves. We chose the latter. One thing we can _NOT_ do, is guarantee the stability of the OS, when it is in early development, which is where things are today.
I fully understood the unstable nature of beta/test releases when I installed test1, having read the caveats and tried other betas over the years; 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.
My $0.02
Phil
P.S. With the low cost of hard disks, I highly recommend keeping a multi-bootable copy of a more stable OS (FC1 in my case) installed if you really need to have something reliable available to get some work done while still enjoying the rawhide roller-coaster ride.
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 Fri, 2004-02-27 at 10:15 -0500, Sandy Pond wrote:
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.
Points taken. Composed my message late last night before the above were written but an ISP outage kept it from going out until this morning.
I want fast moving improvements and fixes. Packages are tested by the developer before going to rawhide for testing.
But many eyes are the reason for testing in the first place.
If this moves to fast for you then get off the rawhide channel but don't slow everyone down.
I'll hang in there as best I (and my cable-modem - currently downloading latest updates) can, thanks. Please don't wait. :^)
Doing as you suggest would severely cripple the testing/bug reporting/ fixing process by adding more internal loops.
Was trying to propose an approach that might increase efficiency of the end-to-end testing process without undue burden to developers, but the above arguments are convincing. Let's keep rolling, rolling...
Phil
Hello All-
This may be expected behavior for KDE, but under the "Logout" menu, there is not the option to restart or shutdown as there is in Gnome. Is this just the way KDE works, or should this be filed as an RFE or bug? (In the interests of maintaining consistency between GNOME and KDE in Fedora, it would be nice if the same menu option exhibited the same behavior...
-Sean
GPG public key: http://homepage.mac.com/smearp/seanpgp.asc
On Sunday 29 February 2004 2:05 am, Sean Earp wrote:
Hello All-
This may be expected behavior for KDE, but under the "Logout" menu, there is not the option to restart or shutdown as there is in Gnome. Is this just the way KDE works, or should this be filed as an RFE or bug? (In the interests of maintaining consistency between GNOME and KDE in Fedora, it would be nice if the same menu option exhibited the same behavior...
-Sean
if you use kdm as your display manager then you can shutdown or reboot the system from kde for some reason when using GDM it doesnt work as you would expect.
you can either remove the gdm package and restart x or edit /etc/sysconfig/desktop and add a line DISPLAYMANAGER="KDM" and restart x and you will get the expected behaviur from kde
Dennis
On Fri, Feb 27, 2004 at 10:15:34AM -0500, Sandy Pond wrote:
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.
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.
(BTW the above stability classes are due to be consolidated to three: production/testing/experimental and for deprecated packages: graveyard)
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, 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? ;)
On Mon, 2004-03-01 at 11:56 +0100, Axel Thimm wrote: ..snip..
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.
I think that a lot of the problems that I see from the testers POV on rawhide stem from;
1. Not getting a clean update to rawhide from FC1 (not recommended). 2. The slow default rawhide repo. 3. The stability of up2date/yum. 4. The pure volume of rawhide updates. 5. The non-syncing of the development mirrors.
I don't think the main problem is rawhide package stability. In general I've found rawhide packages more stable than the original test1 release.
I think that a lot of the problems from a developers POV is duplicate/ bad bug reporting and time management. More testers doesn't necessary translate into better testing.
I'd prefer these issues be attacked head-on first. Unfortunately, you'll never fix the volume issue. Sometimes many packages need to be rebuilt only because of a dependency update, like a gcc update. And many times these large rebuilds can affect overlapping packages. I really don't see moving a package from one segment to another without a rebuild as all that common. Maybe I'm wrong but it seems like stability segmentation of rawhide would be lead to having another development channel. A tanned-hide? And the big question is does this really hurt or help the developer? My thinking is attack the present known problems head-on first and give some more time for things to sort out.
I don't think we disagree. I think we both want the developers needs put first and foremost so that we get to FC2 gold as fast as possible.
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,
-Sean
GPG public key: http://homepage.mac.com/smearp/seanpgp.asc
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
Sandy Pond wrote:
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
Thanks Sandy-
Installing epiphany did fix the problem, but I am now curious as to why Fedora requires a specific browser (just one of many) to open web URLs embedded in an email. Windoze and Mac OS X both open up WHATEVER browser is set to default, whether it be IE, Safari, Opera, Mozilla, or whatever the popular browser of the day is. From a user perspective (especially a somewhat new user), it is A Bad Thing <tm> to require that one specific browser (epiphany) be installed to click on links in an email (a very common user task). 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,
-Sean
On Sun, Mar 14, 2004 at 09:07:00PM -0800, Sean Earp wrote:
Installing epiphany did fix the problem, but I am now curious as to why Fedora requires a specific browser (just one of many) to open web URLs embedded in an email.
Sounds like a bug. It should use 'htmlview'. That one is supposed to check what is available and you can modify a search order for your various browsers in /etc/htmlview.conf, system-wide, or in ~/.htmlviewrc for your own account.
Or "user interface experts" were allowed to that and are making you happy by taking care that you will not get confused.
Michal
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).
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> LCA, RHCE Red Hat Sales Engineer || Aurora SPARC Linux Project Leader
"The author's mathematical treatment of the conception of purpose is novel and highly ingenious, but heretical and, so far as the present social order is concerned, dangerous and potentially subversive. Not to be published." -- Aldous Huxley's "Brave New World"
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 :)
Sandy Pond wrote:
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).
Well, Tom was absolutely correct. Changing my default application allowed me to click on a link and have it open up in Firefox. Is there a KDE equivelent to gnome-default-application-properties? It works fine when I run it from the command line, but as a newbie, I would expect to be able to click on the "System Settings" menu and find an app to change my default applications. As far as I can see, there is none.
Default is epiphany ... but isn't installed by default :)
Any reason I shouldn't file the above as a bug? The default web browser should be the one installed by default, not one that you need to add later or as part of a custom install...
Thanks for the help everyone!
-Sean :)
On Mon, Mar 15, 2004 at 02:14:31AM -0500, Sandy Pond wrote:
On Mon, 2004-03-15 at 00:44, Tom 'spot' Callaway wrote:
browser preference I set with gnome-default-applications-properties (galeon, in my case).
Default is epiphany ... but isn't installed by default :)
That would be one for bugzilla
On Mon, Mar 15, 2004 at 07:24:32PM +0100, Leonard den Ottolander wrote:
Hello Alan,
hat would be one for bugzilla
Not really, as I think evolution has been reverted to 1.4.5 for FC 2 test 1. It will be upgraded to 1.4.6 soon. Correct me if I am wrong.
Ah did I misunderstand you - I thought this was also true of 1.4.5/6 from your earlier email.
Hi Alan,
Ah did I misunderstand you -
I guess so. It can be somewhat confusing to be discussing two different development branches on the same list (see also the window-list-es.omf thread, although that is about the same issue in two branches of gnome-panel). (Which reminds me that to avoid such confusion *always* mentioning version numbers when submitting bug reports in bugzilla is good practice :) .)
I thought this was also true of 1.4.5/6 from your earlier email.
Nope. I am having different issues with 1.4.5-7 on FC 1. Crash when editing the To: field. And on opening the Tools->Settings menu. But the latter I only noticed just now. And it appears to be the same issue, something with e_table_sorter_new().
No problems with opening links in Firefox from 1.4.5-7 though.
Leonard.
On Mon, 2004-03-15 at 15:26 -0500, Alan Cox wrote:
On Mon, Mar 15, 2004 at 07:24:32PM +0100, Leonard den Ottolander wrote:
Hello Alan,
hat would be one for bugzilla
Not really, as I think evolution has been reverted to 1.4.5 for FC 2 test 1. It will be upgraded to 1.4.6 soon. Correct me if I am wrong.
Ah did I misunderstand you - I thought this was also true of 1.4.5/6 from your earlier email.
$ grep epiphany /etc/gconf/schemas/desktop_gnome_url_handlers.schemas <default>epiphany %s</default> <default>epiphany %s</default>
$ rpm -q --file /etc/gconf/schemas/desktop_gnome_url_handlers.schemas gnome-vfs2-2.5.91-1
But maybe epiphany will be the default browser for FC2?
On a side note. I wonder why apps don't register their gnome capabilities, for instance, in their ".desktop" file, so that these don't have to be hard coded in some separate gnome package ... then they can be discovered depending on what's installed? This is exactly how the menus work.
:)
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.
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)
Thanks for the information. This is great stuff for a fedora testing FAQ.
On Thu, 2004-02-26 at 16:59, Mike A. Harris wrote:
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.
Should this not be just another CVS branch for the test release. 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. Where is all of this difficulty coming from? Isn't this basic software development practices.
You do indeed describe the Release process. You have provided great information.
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
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.
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.
also, i still think there's a conflict with rawhide being simultaneously:
1) the proposed next release, and 2) the source of really cool, new, bleeding edge stuff
it's not clear that these two categories represent the same thing. are they supposed to?
what happens to rawhide as RH gets close to an official release and imposes a feature freeze? at that point, there should only be bug fixes, not new versions of software, right? but if that's the case, does that mean the entire rawhide repo is frozen in terms of new releases as well?
put another way, is rawhide ever allowed to get ahead of what's planned for the next release?
rday
also, i still think there's a conflict with rawhide being
simultaneously:
- the proposed next release, and
- the source of really cool, new, bleeding edge stuff
it's not clear that these two categories represent the same thing. are
they supposed to?
Absolutely. Ok, rawhide is what is called a "development snapshot". These are new things which are being worked with for the next version, released to those who are interested in it specifically for feedback on the enhancements.
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.
Are you using your machine regularly? Do you not want to deal with system instability or drivers not loading? Are you NOT looking specifically to help with development and testing? If any of these are true, you don't want a rawhide release, they aren't for you. Rawhide is specifically to grab the latest changes, buggy or not, for feedback and testing purposes.
Same process, rawhide is just individual "bump" updates on the way to "milestones".
--===============-- Wayne S. Frazee
On Fri, 27 Feb 2004, Wayne Frazee wrote:
...
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.
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?
perhaps the package is just too new/untested for RH's comfort level to be put into rawhide, but they'd still love to get feedback on it. perhaps it's too close to an official release and there's been a feature freeze.
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.
rday
p.s. as animated and as heated as this discussion has gotten at times, i just wanted to thank everyone who's put the time into making me understand how all this works. so ... *who's* writing this testing HOWTO? :-)
Robert P. J. Day wrote:
p.s. as animated and as heated as this discussion has gotten at times, i just wanted to thank everyone who's put the time into making me understand how all this works. so ... *who's* writing this testing HOWTO? :-)
you ? ;-)
http://fedora.redhat.com/participate/documentation-faq/ http://fedora.redhat.com/projects/docs/
Robert P. J. Day said:
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?
You've seen it in messages to this list:
ftp://people.redhat.com/mharris/testing/unstable/pine ftp://people.redhat.com/jakub/openoffice.org/ http://people.redhat.com/~veillard/testing/FC1/i386/rhn-applet/
All from posts to this list asking for testing.
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?
perhaps the package is just too new/untested for RH's comfort level to be put into rawhide, but they'd still love to get feedback on it. perhaps it's too close to an official release and there's been a feature freeze.
I believe your question was answered;
http://www.redhat.com/archives/fedora-test-list/2004-February/msg01818. html
On Fri, 27 Feb 2004, Robert P. J. Day wrote:
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?
Sure. Individual developers can opt to do that (or not do that) on a package by package basis at their own leisure. I put my packages up on people.redhat.com in an ftp and yum accessible fashion.
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.
Yes, but only as unofficial unsupported packages. Our efforts are spent on actually developing and maintaining what _will_ be used in the next OS release, rather than /what would be nice to have because it is newer and some people out there might like it/ per se. Individual developers can of course update packages however they like and provide them on people.redhat.com, or in fedora.us or somewhere else. But that really isn't part of developing Fedora Core 2. It's more fun stuff for people who want something newer for given specific packages. We're more concerned about what we actually will be shipping.
On Fri, 27 Feb 2004, Wayne Frazee wrote:
also, i still think there's a conflict with rawhide being
simultaneously:
- the proposed next release, and
- the source of really cool, new, bleeding edge stuff
it's not clear that these two categories represent the same thing. are
they supposed to?
Absolutely. Ok, rawhide is what is called a "development snapshot". These are new things which are being worked with for the next version, released to those who are interested in it specifically for feedback on the enhancements.
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.
Are you using your machine regularly? Do you not want to deal with system instability or drivers not loading? Are you NOT looking specifically to help with development and testing? If any of these are true, you don't want a rawhide release, they aren't for you. Rawhide is specifically to grab the latest changes, buggy or not, for feedback and testing purposes.
Same process, rawhide is just individual "bump" updates on the way to "milestones".
That is a very nice way of describing rawhide. You've hit the nail square on the head. ;o)
On Friday 27 February 2004 3:29 am, Robert P. J. Day wrote:
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)?
No. Rawhide has no commitments. You should have seen Rawhide prior to the release of Red Hat 7.3. Seeing gcc 3 go in, then come back out, was an eye-popper. Many people did see it, and confusion was all over the place on the public lists. Those 'in the know' were even more taken aback.
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?
Yes. Packages get retrograded.
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.
Yes, it has 'suboptimal' consequences. You can't guarantee update. Again, prior to RH 7.3, when Rawhide had gcc 3 in it, then was reverted to gcc 2.96, lots of things broke. Ask Jonathan Kamens about it. Rawhide is not ever guaranteed to update to anything else ever. Period. It is just where development is *right now* and that's all. JIK regularly and constantly tracks (or used to track) Rawhide, and posted about it regularly.
- the proposed next release, and
- the source of really cool, new, bleeding edge stuff
With Fedora, 1=2.
put another way, is rawhide ever allowed to get ahead of what's planned for the next release?
Yes. Then before release Rawhide slows down and 'chills' to an extent.
On Fri, 27 Feb 2004, Robert P. J. Day wrote:
Date: Fri, 27 Feb 2004 03:29:54 -0500 (EST) From: Robert P. J. Day rpjday@mindspring.com To: fedora-test-list@redhat.com Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: For testers of Fedora Core development releases <fedora-test-list.redhat.com> Subject: Re: Testing test releases: do not update
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.
Sorry, I was a bit unclear there. To clarify:
What is in rawhide at any given point in time, is what is currently planned to go into the final OS release, unless something occurs that requires either updating the package with bug fixes, or updating it to a new upstream release, or downgrading the package or removing it entirely, possibly replacing it with an alternate package with similar or identical functionality.
The idea, is that what is in rawhide is "current plan to ship" and if people aren't testing it, they aren't testing what is in the current plans. The plans may of course change, and the code could as I mention above, be downgraded/upgraded/removed/replaced.
also, i still think there's a conflict with rawhide being simultaneously:
- the proposed next release, and
- the source of really cool, new, bleeding edge stuff
it's not clear that these two categories represent the same thing. are they supposed to?
The definition of rawhide is "our current internal tree, consisting of the latest bits including new bleeding edge stuff, bug fixes, code-in-testing, and other stuff that is planned to go into the next OS release, which are subject to change at a date in the future should the need arise". Or something to that effect.
what happens to rawhide as RH gets close to an official release and imposes a feature freeze? at that point, there should only be bug fixes, not new versions of software, right? but if that's the case, does that mean the entire rawhide repo is frozen in terms of new releases as well?
Exactly.
put another way, is rawhide ever allowed to get ahead of what's planned for the next release?
No. Rawhide is the rolling set of packages that will comprise the next OS release eventually. Nothing goes into rawhide unless it is destined to be in the final OS release. So you won't for example see Fedora Core 3 development packages going into rawhide until after Fedora Core 2 is gold mastered and shipped as an official OS release.
As each Fedora Core 2 milestone is reached, feature freezes get hit, and code freezes, string freezes, etc. If you look at the target milestones on our website:
http://fedora.redhat.com/participate/schedule/
That outlines what type of changes have to be in the tree by which date (barring date slips). You'll notice that March 12 is the current date planned by which any package version updates must be in by. Any package version update that has not been done by that date will not get updated unless we've already planned on some exceptions, such as the listed GNOME exception. There are sometimes other exceptions as well, but generally we do not upgrade package versions beyond that point except for compelling reasons.
On Friday 27 February 2004 01:39, Mike A. Harris wrote:
- 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 -- I suggest that there is another option and that is to not use the early ("alpha") snapshots but wait for the later ones ... the ones which are more analogous to what was available in public beta in the previous process.
As others have pointed out, with the new more open process all users are being exposed to the rough edges which previously were hidden from most users and only encountered by the limited set of private testers.
I am now in the process of reinstalling the FC2-T1 snapshot (which will then be carefully updated to current rawhide) because the updates I applied yesterday made my test system unusable (root partition hosed for some reason). Was this expected ... no. Was I surprised ... no. Am I annoyed ... not really. This is all part of early testing. Fortunately for me I keep all of the accumulated updates I apply in a local repository which I use to apply updates to my test systems ... it will be time consuming but I should be able to apply the fixes in a selective manner to help identify the package causing the problem.
In hindsight, the test process (early snapshots are alpha, later snapshots are beta, development/rawhide are current updates) should have been described so that users would have a better idea of what to expect.
On Thu, 26 Feb 2004, Mike A. Harris wrote:
...
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.
and this is something that would have cleared up a *lot* of my confusion, since it makes perfect sense. but it does have one interesting consequence.
since, in the past, RH internally did some level of testing before releasing the first beta on the world, even that first beta was surprisingly stable. and that meant that, despite the graphic warnings that beta software might explode into flame, render you sterile or possibly EAT ALL THE CHEESE IN YOUR HOUSE!, a lot of gung-ho folks threw caution to the winds, backed up their systems, and just installed it anyway. and, barring the inevitable annoyances and broken pieces, things went fairly well and RH got a *lot* of bug reports from folks (myself included) that dived into the deep end.
but with the new release schedule, those warnings suddenly seem a lot more meaningful. it suggests that even those of us who want to jump right in might want to wait until -test2 before installing to use on a 24x7 basis and, until then, really have a separate system just for testing.
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.
rday
On Fri, 2004-02-27 at 05:42, Robert P. J. Day wrote:
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.
Hard to say actually during this testing phase. This first -test1 seemed a little more stable than the original beta releases to the private team. Mostly the installer was the main test during the first beta, and then the components afterwards once you got it installed. Of course, as Jeremy had mentioned, this first -test release wasn't built for all arches to install on.
But, I think we'd have to wait until after FC2 goes live to see how the test releases were compared to the beta releases. (Remember, there are a lot more people helping to test now than before, so even harder to say)