I have been battling all morning on trying to get yum working, and no matter what I have done, I can not get a successful connection. I get this message:
Server: Fedora Linux 1.90 - i386 - core Finding updated packages Downloading needed headers retrygrab() failed for:
http://ayo.freshrpms.net/fedora/linux/1.90/i386/core/headers/xosview-0-1.8.0... Executing failover method failover: out of servers to try Error getting file http://ayo.freshrpms.net/fedora/linux/1.90/i386/core/headers/xosview-0-1.8.0... [Errno 7] HTTP Error (CannotSendRequest):
I am using:
baseurl=http://mirror.hiwaay.net/redhat/fedora/linux/core/development/$basearch
and everything seems to be working fine. Maybe try that server? HTH, Kevin --- Kevin Worthington - <kworthington (at) linuxmail {dot} org> Red Hat Linux user since April 1998 Fedora Core User since July 2003 (Severn betas) Registered Linux User #218689 - http://counter.li.org
On Fri, Feb 20, 2004 at 11:29:48AM -0500, Kevin Worthington wrote:
I have been battling all morning on trying to get yum working, and no matter what I have done, I can not get a successful connection. I get this message:
Server: Fedora Linux 1.90 - i386 - core Finding updated packages Downloading needed headers retrygrab() failed for:
http://ayo.freshrpms.net/fedora/linux/1.90/i386/core/headers/xosview-0-1.8.0... Executing failover method failover: out of servers to try Error getting file http://ayo.freshrpms.net/fedora/linux/1.90/i386/core/headers/xosview-0-1.8.0... [Errno 7] HTTP Error (CannotSendRequest):
It works here.
I am using:
baseurl=http://mirror.hiwaay.net/redhat/fedora/linux/core/development/$basearch
and everything seems to be working fine. Maybe try that server?
That is development not FC2test1, but
baseurl=http://mirror.hiwaay.net/redhat/fedora/linux/core/test/1.90/i386/os/
should work.
Axel Thimm wrote:
baseurl=http://mirror.hiwaay.net/redhat/fedora/linux/core/development/$basearch
and everything seems to be working fine. Maybe try that server?
That is development not FC2test1, but
baseurl=http://mirror.hiwaay.net/redhat/fedora/linux/core/test/1.90/i386/os/
should work.
You want development for updates. The core/test/1.90/i386/os is for the initial install. It *seems* that just about every package has been updated since then. The stock yum.conf that ships uses the devel tree - and the Red Hat folks here have suggested that you pull updates from there.
I imagine come FC2 Test 2 or 3, they may split the updates to updates/test/1.91 or something like that in order to provide us with a more stable testing ground.
-Rick
Rick Johnson wrote:
I imagine come FC2 Test 2 or 3, they may split the updates to updates/test/1.91 or something like that in order to provide us with a more stable testing ground.
i am sure that test2 will be more stable than test1
nobody tells you that you must have a fully rawhide system while testing. i am surely no hardcore-tester or bug-hunter and i update only the packages i really need or i will test. --> my test1 is relative stable and i have not the time to solve the evtl. bad surprises after a fully rawhide update
and please, do not add unnecessary directories, symlinks, url-redirections, announcements for test or rawhide, the development is fast and the schedule is aggressive.
sorry, but i have the feeling that redhat had sometimes lost the overview over all the directories, symlinks, url-redirections, schedule from testing to upates and announcement here and announcement there, ...
it should imho be enough that we get a test1|2|3 and the updates via rawhide
On Sat, Feb 21, 2004 at 11:24:16AM -0800, Rick Johnson wrote:
You want development for updates. The core/test/1.90/i386/os is for the initial install. It *seems* that just about every package has been updated since then. The stock yum.conf that ships uses the devel tree - and the Red Hat folks here have suggested that you pull updates from there.
I imagine come FC2 Test 2 or 3, they may split the updates to updates/test/1.91 or something like that in order to provide us with a more stable testing ground.
I would think the reason to have a test release is to have a well defined point in development time to test against. If you point your package resolvers to development/rawhide, then that's what you will be testing instead.
E.g. if you want to have FC2test1 installed and tested, file bug reports etc., then do not update. Or if you do, probably you should not file bugs against FC2test1 anymore (but FC devel), as the set of bugs will already be different.
All from my humble understanding of the current release process/policy, Red Hatters feel free to shoot and correct me ;)
On Sun, 22 Feb 2004, Axel Thimm wrote:
On Sat, Feb 21, 2004 at 11:24:16AM -0800, Rick Johnson wrote:
You want development for updates. The core/test/1.90/i386/os is for the initial install. It *seems* that just about every package has been updated since then. The stock yum.conf that ships uses the devel tree - and the Red Hat folks here have suggested that you pull updates from there.
I imagine come FC2 Test 2 or 3, they may split the updates to updates/test/1.91 or something like that in order to provide us with a more stable testing ground.
I would think the reason to have a test release is to have a well defined point in development time to test against. If you point your package resolvers to development/rawhide, then that's what you will be testing instead.
exactly. see below.
E.g. if you want to have FC2test1 installed and tested, file bug reports etc., then do not update. Or if you do, probably you should not file bugs against FC2test1 anymore (but FC devel), as the set of bugs will already be different.
against my better judgment, i'm going to take one last stab at explaining why i think the current testing procedure is badly defined, because axel's post matches nicely some of my concerns.
let's start simple. as an example of the testing process, red hat releases a "test" version -- at the moment, that's FC2-t1. so far, so good. and red hat obviously wants folks to download, install and beat on that test release and report bugs/errors/issues/whatever. it all sounds so simple, but here's where it starts to break down.
guaranteed, within minutes of release, testers will start to find problems. and i don't mean things to go on a wish list, or request for enhancements. i mean things that are really and truly borked. so they wander over to bugzilla and file a report against ... what? well, obviously, against FC2-t1, right? again, so far, so good. but what to do about features that are truly broken?
the first question is, if testers are claiming to test FC2-t1, should they be allowed to change/update their systems in any way? well, sure, you say. some of those bugs could be serious enough that they get in the way of further testing, so of course, red hat will quickly release some "updated" RPMs to fix the more serious problems so that testers can get on with the business of testing and find even more problems.
but the instant someone applies an updated RPM to their FC2-t1 system, is it technically a FC2-t1 system any more? sure, i'm being pedantic, but this is going to become an issue a bit later. so the question remains, once i start applying red hat updates to my system, at what point have i changed it enough so that it's no longer really an FC2-t1 system? would i have to start reporting bugs against some other release? (don't answer that yet.)
so, *knowing* that there will be bugs and, consequently, updated RPMs, where can one quickly and conveniently get those RPMs? on the one hand, red hat could make everyone painfully and laboriously update packages individually, which means 1,000 testers will almost certainly have 1,000 slightly different test systems -- an obvious nightmare. or red hat could make everyone's life easy (including their own) and give everyone a single channel (in yum.conf) against which they could do a simple "yum update". the beauty of that is that 1) it's easy for testers to keep up to date, and 2) it guarantees that everyone who uses that channel is running the same updated system, so that there's some consistency in bug reports. and what single channel would that be?
as it stands, FC2-t1 was shipped with yum.conf pointing at rawhide. and what a bad idea that was. as more than one person has pointed out, rawhide represents the latest, greatest, bleeding edge, not-even-guaranteed-to-work software. why on earth would anyone ship a test system which is set up to update against rawhide? (rick johnson above claims that red hat actually *recommends* people update against rawhide. say what? given that at least one other poster has emphasized that stuff in rawhide isn't even guaranteed to work? i think someone needs to get their story straight. but, onward.)
in order to make the testing process as useful as possible, one would think that red hat wants to at least partially control how far someone can deviate from the initial FC2-t1 install. testers should be able to update to fix identified and known bugs, that makes sense. but what's the point of updating against rawhide? it would make far more sense to have just an "update" repo for test releases, representing just those packages that were found to be broken. if, instead, you update against rawhide, it would seem you've so contaminated your original system, can you even call it FC2-t1 anymore?
and for those who think it's too much work for red hat to do it this way, i submit that it's exactly the opposite. when there's a test release out in the wild, red hat should be spending their time dealing with bug reports that represent things that are just flat out *broken*. not stuff from rawhide, not RFEs, not wish lists. they should be focused on fixing stuff that's broken, and that means restricting their attention to just those things so that the testers' time is well spent. and that means not having to deal with rawhide. there should be a *separate* update channel purely for fixing broken things. and, no, i don't care if it takes red hat a few more minutes to set this up. it's not about *them*, it's about making the testers' time as productive as possible. but wait, there's more.
on a final note, if you start with FC2-t1, it makes sense that you'll report bugs against the release at bugzilla. but once you start updating your test system, do you still report against FC2-t1? i would think so, but if you go to bugzilla, you'll notice that, in addition to the standard FC1, FC2, test1 and so on, there a fedora core "devel" version. what the heck is "devel" in terms of a version? when would you ever file or query against "fedora core devel"?
anyway, what would be nice is if there was a real and comprehensive document for testers, explaining how releases work, how to query bugs, how to report bugs and so on. and by "comprehensive", i mean something a little more meaty than "file bugs at bugzilla against your current release."
i'm convinced that the testing procedure deserves an update repo, and i'm just as convinced that that repo shouldn't be rawhide.
thoughts?
rday
p.s. i'm just a bit amused by rick johnson's statement that,
I imagine come FC2 Test 2 or 3, they may split the updates to updates/test/1.91 or something like that in order to provide us with a more stable testing ground.
i could have *sworn* that this is the very suggestion i made recently, and it was thoroughly shot down by someone who claimed that it was just waaaaaay too much work for red hat to implement. apparently not.
once again, some people should get their stories straight.
[snip]
as it stands, FC2-t1 was shipped with yum.conf pointing at rawhide. and what a bad idea that was. as more than one person has pointed out, rawhide represents the latest, greatest, bleeding edge, not-even-guaranteed-to-work software. why on earth would anyone ship a test system which is set up to update against rawhide? (rick johnson above claims that red hat actually *recommends* people update against rawhide. say what? given that at least one other poster has emphasized that stuff in rawhide isn't even guaranteed to work? i think someone needs to get their story straight. but, onward.)
From the Fedora Project website:
"It is also a proving ground for new technology that may eventually make its way into Red Hat products."
From the Fedora Project Objectives:
"Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades."
Rawhide is being assessed because it is new technology and making a test of it for speed comparison and possible bugs makes a hell of a lot more sense with a test release than it does just throwing it into a production build. The test1 makes an ideal platform to test rawhide. Right, right now rawhide isnt guarenteed to work. If it breaks on you or messes up, report it. Thats what this TEST is all about.
in order to make the testing process as useful as possible, one would think that red hat wants to at least partially control how far someone can deviate from the initial FC2-t1 install. testers should be able to update to fix identified and known bugs, that makes sense. but what's the point of updating against rawhide? it would make far more sense to have just an "update" repo for test releases, representing just those packages that were found to be broken. if, instead, you update against rawhide, it would seem you've so contaminated your original system, can you even call it FC2-t1 anymore?
[snip]
How would you suggest to define development builds? Just put everything against the core? Zero version control? Issue some sort of arbitrary version identifier with each update which then has to be included with bugzilla reports?
Wayne S. Frazee (#Fedora user: wfrazee)
Robert P. J. Day wrote:
against my better judgment, i'm going to take one last stab at explaining why i think the current testing procedure is badly defined
afair in previous tests: the schedule was ~ 1,5 month no preconfigured *default* update channel
let's start simple. as an example of the testing process, red hat releases a "test" version -- at the moment, that's FC2-t1. so far, so good. and red hat obviously wants folks to download, install and beat on that test release and report bugs/errors/issues/whatever. it all sounds so simple,
testing is not a simple act! it is procedure you have to learn through your experiences and the feedback through the "test-list" or bugzilla
but here's where it starts to break down.
guaranteed, within minutes of release, testers will start to find problems.
you will read ~ 1000 times the same questions on this TEST-LIST
some of those bugs could be serious enough
who will claim "serious enough" ? if you never use samba i bet that you are not interested in this bugs
that they get in the way of further testing,
rawhide
so of course, red hat will quickly release some "updated" RPMs to fix the more serious problems so that testers can get on with the business of testing and find even more problems.
rawhide
so, *knowing* that there will be bugs and, consequently, updated RPMs, where can one quickly and conveniently get those RPMs?
rawhide
on the one hand, red hat could make everyone painfully and laboriously update packages individually, which means 1,000 testers will almost certainly have 1,000 slightly different test systems -- an obvious nightmare.
for test1 and test2 evtl. the best ground for finding sleeping bugs
or red hat could make everyone's life easy (including their own) and give everyone a single channel (in yum.conf) against which they could do a simple "yum update".
yum update samba*
the beauty of that is that 1) it's easy for testers to keep up to date, and 2) it guarantees that everyone who uses that channel is running the same updated system, so that there's some consistency in bug reports. and what single channel would that be?
you will file bugs against eg. test1-update1 20040214 10:00 test1-update2 20040214 13:24 test1-update3 20040215 15:23 test1-update4 20040215 15:31 ...
and this in this aggressive schedule ?
as it stands, FC2-t1 was shipped with yum.conf pointing at rawhide. and what a bad idea that was. as more than one person has pointed out, rawhide represents the latest, greatest, bleeding edge, not-even-guaranteed-to-work software.
this is testing and you make the decission for yourselve what you need or what you want
why on earth would anyone ship a test system which is set up to update against rawhide?
you will a nanny-testing ?
p.s. i'm just a bit amused by rick johnson's statement that,
I imagine come FC2 Test 2 or 3, they may split the updates to updates/test/1.91 or something like that in order to provide us with a more stable testing ground.
i could have *sworn* that this is the very suggestion i made recently, and it was thoroughly shot down by someone who claimed that it was just waaaaaay too much work for red hat to implement. apparently not.
imho it is not necessary, "the development is fast and the schedule is aggressive."
it would make more sense with a longer time between test1 test2 test3.
On Sun, 22 Feb 2004, shrek-m@gmx.de wrote:
Robert P. J. Day wrote:
let's start simple. as an example of the testing process, red hat releases a "test" version -- at the moment, that's FC2-t1. so far, so good. and red hat obviously wants folks to download, install and beat on that test release and report bugs/errors/issues/whatever. it all sounds so simple,
testing is not a simple act!
i didn't *say* it was simple, i said (if you'd read it again) that it *sounds* simple if it's described as i did above. i wrote that as a prelude to the rest of my post, where i went to great pain to point out that it was anything *but* simple. sheesh.
some of those bugs could be serious enough
who will claim "serious enough" ? if you never use samba i bet that you are not interested in this bugs
oh, come on, get a grip. i think my point was pretty clear. testing should uncover bugs that are annoying or crippling enough that they should be patched for the sake of testers being able to make more progress. it doesn't matter if *some* people don't use samba. it's clear that if someone finds a serious bug in samba during testing, it should be patched if possible so the people who *are* testing it can continue.
this sort of update is clearly different from, say, upgrading from KDE 3.1.5 to 3.2, for example, which would be proposed just for getting new features. are you seriously suggesting that you don't recognize the fundamental difference between upgrading because you want a new package with newer features, and upgrading to fix a significant bug?
from what i've read so far, the consensus is that testers are encouraged to update against rawhide and to file bug reports on all of those updates. i think that's a silly idea. it's silly because rawhide is defined as the repository for the latest, greatest, still-wet releases of software that have absolutely no guarantee of working and, IMHO, it's does a disservice to testers to ask for their time to test, and then give them what is essentially a moving target.
however, it's obvious that i'm thoroughly outvoted, so i'll just defer to the majority.
rday
Hello all, is the tclx package missing from this test release? I've done an install everything and tcl does not seem to be available. I've also tried to yum it with no success. This package seems to be available with no problem in core 1. I'm trying to build a piece of software that requires it and am currently blocked. I'm sure I could find a rpm on the net but would rather use the version intended for this fedora release. Any thoughts would be appreciated. Regards Mike Pedersen
Hi Mike,
"MP" == Mike Pedersen mike.pedersen@sbcglobal.net writes:
MP> is the tclx package missing from this test release?
Yes, well spotted. tclx should hopefully be in FC devel in time for test2.
tclx used to be part of the tcltk "megapackage", which has been split up into individual srpms for FC2 - a new individual tclx srpm is nearly ready. emacspeak also requires it I believe.
Cheers, Jens
Hi Jens, thanks much for the answer. Is it possible to get a pre-release version of these packages from somewhere before the official release?
regards Mike Pedersen
-----Original Message----- From: fedora-test-list-admin@redhat.com [mailto:fedora-test-list-admin@redhat.com] On Behalf Of Jens Petersen Sent: Sunday, February 22, 2004 1:24 PM To: fedora-test-list@redhat.com Cc: Mike Pedersen Subject: Re: Is tclx missing from test 1
Hi Mike,
"MP" == Mike Pedersen mike.pedersen@sbcglobal.net writes:
MP> is the tclx package missing from this test release?
Yes, well spotted. tclx should hopefully be in FC devel in time for test2.
tclx used to be part of the tcltk "megapackage", which has been split up into individual srpms for FC2 - a new individual tclx srpm is nearly ready. emacspeak also requires it I believe.
Cheers, Jens
"MP" == Mike Pedersen mike.pedersen@sbcglobal.net writes:
MP> Is it possible to get a pre-release version of these MP> packages from somewhere before the official release?
tclx-8.3.5-1 should be in FC devel (rawhide) by now.
Jens
On Sun, Feb 22, 2004 at 03:57:58PM -0500, Robert P. J. Day wrote:
from what i've read so far, the consensus is that testers are encouraged to update against rawhide and to file bug reports on all of those updates. i think that's a silly idea. it's silly because rawhide is defined as the repository for the latest, greatest, still-wet releases of software that have absolutely no guarantee of working and, IMHO, it's does a disservice to testers to ask for their time to test, and then give them what is essentially a moving target.
Rawhide is the current edge of the wave. Without people testing stuff that hits rawhide everyone just gets stuck at the bugs which may already have been fixed, or files reports on fixed problems.
If you hit a bug in a given package you really want to try the rawhide version in case someone has fixed it. There is a fair change it has been fixed already with the most glaring bugs (eg my panel menu works after the update) although the kernel seems to still have problems and the root menu translations are *STILL* broken (gripe gripe ;))
Alan
On Sun, 22 Feb 2004, Alan Cox wrote:
On Sun, Feb 22, 2004 at 03:57:58PM -0500, Robert P. J. Day wrote:
from what i've read so far, the consensus is that testers are encouraged to update against rawhide and to file bug reports on all of those updates. i think that's a silly idea. it's silly because rawhide is defined as the repository for the latest, greatest, still-wet releases of software that have absolutely no guarantee of working and, IMHO, it's does a disservice to testers to ask for their time to test, and then give them what is essentially a moving target.
Rawhide is the current edge of the wave. Without people testing stuff that hits rawhide everyone just gets stuck at the bugs which may already have been fixed, or files reports on fixed problems.
argh! is it too much to ask that people respond to what i actually *wrote* rather than what they *imagine* i wrote. i never said that people should never update against rawhide -- feel free to go back and find a single posting where i discourage that.
what i was suggesting is that testers have the *choice* as to whether they want to update against rawhide. if you're feeling gung-ho and ready to rock and want to take the stuff in rawhide for a spin, then by all means, go wild.
but for those who aren't quite so devil-may-care, i still don't think it's out of line to give *those* folks a more stable update channel which represents just those things that are clearly broken. how many times do i have to type that sentiment before people understand it? should i type more slowly? what?
let's understand something pretty fundamental about the historical RH testing process. as we all know, RH has massive disclaimers about test releases -- don't use them for serious, mission-critical stuff, they're almost guaranteed to be a bit flaky, etc, etc. the standard recommendation is, of course, to install a test release perhaps in a *second* partition, dual boot to it when you want to test, *don't* fer cryin' out loud use it in a production environment. you get the idea.
but let's face it, it doesn't quite happen that way. given that even test releases of RH are, for the most part, pretty solid, a lot of people (moi included) *will* install it on our desktops. in short, despite all the warnings that it's alpha, many of us will in fact bite the bullet, take a deep breath, and load that baby. we *know* we'll run into bugs, we *know* we're going to have to work around glitches, but we're prepared to pay the price to play with the latest and greatest.
and, you'll notice, it's from those testers that RH will get the most useful feedback. not from the occasional, pop-into-test-release-for-a-while-and-dick-around testers, but from the aforementioned, damn-the-torpedoes, here we go with the alpha release, 24x7, "i'm going to immerse myself in it and live with the consequences no matter what" testers. these are the people who are making a fair sacrifice taking that kind of chance and putting up with the inevitable bugs and reporting them. and in return, what do they get?
i submit, what they get is being treated like crap by red hat.
if i'm prepared to install and live with an alpha release and its initial bugs, the one consolation i might get is that, as time goes by and bugs are reported and patches and updates issues, i can at least look forward to my system getting more and more stable, having to deal with fewer and fewer bugs (at least until the next test release). i can live with the initial pain because i can look forward to life, slowly but surely, getting better and better. and as things get better, i might even start re-customizing my working environment, getting back to where it was before, life mercifully returning to something resembling normal.
but this won't happen as long as the only update channel is rawhide since, if i update against rawhide, *by* *definition*, i know that i'll get not only the patches i want, but all of the other untested, bleeding-edge development crud that's been dumped in there that red hat would like people to play with. in short, while part of my system is being fixed, almost guaranteed, some other part is now broken. one step forward, one step back?
so what's in it for the tester? just the guarantee that, as some bugs are fixed, others are introduced. who would want to live in that kind of environment 24x7? (and keep in mind, i'm addressing specifically that population of testers who are making the sacrifice to immerse themselves in the test release and from whom RH is undoubtedly getting the most feedback. giving them nothing but rawhide is basically telling them, "for all of your hard work and sacrifice and commitment, we're going to treat you like a guinea pig and load your machine with stuff that we haven't had time to really look at yet. let us know if something explodes. thanks.")
oh, and let's not forget the most pernicious argument of all. at least a few posters have suggested that having two update channels -- one for straight fixes, the other being rawhide -- is just, well, too much work, it's infeasible, how would you implement it?
gee, i don't know -- perhaps the same way that RH implements the various channels for its production releases: base, updates, testing-updates and, finally, rawhide. apparently, *someone* at RH understands the concept of different quality levels of download channels. so what's the problem?
anyway, i've spent way too much time on this. used to be, i always looked forward to a new RH/fedora release, even knowing the glitches i'd have to put up with.
but if RH's approach to automatic updates and bug fixes for test releases is to simply cram onto my machine all of the untested, buggy stuff from rawhide, well, that kind of loses its appeal.
rday
Robert P. J. Day said:
from what i've read so far, the consensus is that testers are encouraged to update against rawhide and to file bug reports on all of those updates. i think that's a silly idea. it's silly because rawhide is defined as the repository for the latest, greatest, still-wet releases of software that have absolutely no guarantee of working and, IMHO, it's does a disservice to testers to ask for their time to test, and then give them what is essentially a moving target.
By definition Test releases are snapshots of Rawhide. During the testing phase Rawhide is expected to be working (IE it has to be working to produce Test2). Your view of Rawhide as "still-wet" is correct for the time between FC2 and FC3test1.
Again, if you don't do testing against the fixes that are posted in Rawhide, Test2 just comes out broken in "new and interesting ways"(tm) and we would never get to the level of a release. The goal is to make each Test release tested more than the last, not start over every Test.
Robert P. J. Day wrote:
it's clear that if someone finds a serious bug in samba during testing, it should be patched if possible so the people who *are* testing it can continue.
this sort of update is clearly different from, say, upgrading from KDE 3.1.5 to 3.2, for example, which would be proposed just for getting new features. are you seriously suggesting that you don't recognize the fundamental difference between upgrading because you want a new package with newer features, and upgrading to fix a significant bug?
http://fedora.redhat.com/participate/schedule/
KDE 3.2 23 January test1 devel freeze
http://download.fedora.redhat.com/pub/fedora/linux/core/test/1.90/i386/os/Fe... http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fed...
On Sun, 22 Feb 2004, shrek-m@gmx.de wrote:
Robert P. J. Day wrote:
it's clear that if someone finds a serious bug in samba during testing, it should be patched if possible so the people who *are* testing it can continue.
this sort of update is clearly different from, say, upgrading from KDE 3.1.5 to 3.2, for example, which would be proposed just for getting new features. are you seriously suggesting that you don't recognize the fundamental difference between upgrading because you want a new package with newer features, and upgrading to fix a significant bug?
http://fedora.redhat.com/participate/schedule/
KDE 3.2 23 January test1 devel freeze
sorry, i just wanted to come up with a hypothetical example and KDE leaped to mind.
rday
Robert P. J. Day (rpjday@mindspring.com) said:
I would think the reason to have a test release is to have a well defined point in development time to test against. If you point your package resolvers to development/rawhide, then that's what you will be testing instead.
Yes. Oddly enough, that's what will become the release eventually.
or red hat could make everyone's life easy (including their own) and give everyone a single channel (in yum.conf) against which they could do a simple "yum update". the beauty of that is that 1) it's easy for testers to keep up to date, and 2) it guarantees that everyone who uses that channel is running the same updated system, so that there's some consistency in bug reports. and what single channel would that be?
The development channel. As it is.
as it stands, FC2-t1 was shipped with yum.conf pointing at rawhide. and what a bad idea that was. as more than one person has pointed out, rawhide represents the latest, greatest, bleeding edge, not-even-guaranteed-to-work software.
It's also what will become the release.
to fix identified and known bugs, that makes sense. but what's the point of updating against rawhide? it would make far more sense to have just an "update" repo for test releases, representing just those packages that were found to be broken. if, instead, you update against rawhide, it would seem you've so contaminated your original system, can you even call it FC2-t1 anymore?
No, you call it the FC development tree. There's even a bugzilla bucket for it.
and for those who think it's too much work for red hat to do it this way, i submit that it's exactly the opposite. when there's a test release out in the wild, red hat should be spending their time dealing with bug reports that represent things that are just flat out *broken*. not stuff from rawhide, not RFEs, not wish lists.
Except, a great majority of the RFEs and wish lists aren't filed until the first test release is up. Aside from that...
and that means not having to deal with rawhide. there should be a *separate* update channel purely for fixing broken things.
This is a broken implementation.
If you run stock FC2 Test1: you're running a tree that's a snapshot, at a point in time, of what will be FC2.
If you then update to rawhide as of a certain date: you're running a tree that's a snapshot, at a point in time, of what will be FC2.
If you have a separate test updates channel: you're running a tree that is *not* a snapshot of what will be FC2, but a mix and match of various packages. Many of which may not be fully up to date.
Bugs against the first two are inherently more useful than bugs against the third.
Bill
Axel Thimm said:
I would think the reason to have a test release is to have a well defined point in development time to test against. If you point your package resolvers to development/rawhide, then that's what you will be testing instead.
E.g. if you want to have FC2test1 installed and tested, file bug reports etc., then do not update. Or if you do, probably you should not file bugs against FC2test1 anymore (but FC devel), as the set of bugs will already be different.
The point you are missing is that FC2test2 will just be another snapshot from FC devel. If everyone is running FC2test1 and not updating then FC2test2 will come out basically untested. This is not what we want.
My experience from the Severn beta says that "test" releases are expected to be updated from Rawhide (devel) so that:
- Everyone doesn't keep reporting bugs that have been fixed - Everyone can test what will become Test2
On Sun, Feb 22, 2004 at 12:06:06PM -0500, William Hooper wrote:
Axel Thimm said:
I would think the reason to have a test release is to have a well defined point in development time to test against. If you point your package resolvers to development/rawhide, then that's what you will be testing instead.
E.g. if you want to have FC2test1 installed and tested, file bug reports etc., then do not update. Or if you do, probably you should not file bugs against FC2test1 anymore (but FC devel), as the set of bugs will already be different.
The point you are missing is that FC2test2 will just be another snapshot from FC devel.
Who would imagine that? ...
If everyone is running FC2test1 and not updating then FC2test2 will come out basically untested. This is not what we want.
Doesn't this reduce FCtest1 to an installer for rawhide with a test for anaconda? Given the possibilities provided by modern package resolvers like apt/yum you can jump on rawhide much easier than sucking iso images to be outdated the next day.
My experience from the Severn beta says that "test" releases are expected to be updated from Rawhide (devel) so that:
- Everyone doesn't keep reporting bugs that have been fixed
- Everyone can test what will become Test2
Axel Thimm said:
If everyone is running FC2test1 and not updating then FC2test2 will come out basically untested. This is not what we want.
Doesn't this reduce FCtest1 to an installer for rawhide with a test for anaconda?
If Severn is any indication, yes.
William Hooper said:
My experience from the Severn beta says that "test" releases are expected to be updated from Rawhide (devel) so that:
I knew I had read it "official" somewhere:
http://fedora.redhat.com/download/updates.html
"Development Packages
Lastly, there are development packages. These packages are untested and still under development. This is where updates for test releases will be found. "