I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward.
Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. So now in this test environment mail is completely useless.
Is there a way to encourage, or preferably enforce, keeping the wavefront coherent?
edge
On Mon, 2005-01-31 at 10:11 -0600, Edginton, Brian (GE Healthcare) wrote:
I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward.
Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. So now in this test environment mail is completely useless.
Is there a way to encourage, or preferably enforce, keeping the wavefront coherent?
edge
If you have an important workstation/server, you really shouldn't be running from Rawhide. Things get out of sync, break, get your cat pregnant, etc. all the time. You can't expect real stability until the few weeks prior to release when everything freezes and the various glitches are worked out. If there was any mandate to keep Rawhide stable at all times, it would be the equivalent of production and they would have to put out Beta/RC releases for Rawhide! Then we'd never see anything go anywhere.
Le lundi 31 janvier 2005 à 13:22 -0500, David Hollis a écrit :
If you have an important workstation/server, you really shouldn't be running from Rawhide. Things get out of sync, break, get your cat pregnant, etc. all the time. You can't expect real stability until the few weeks prior to release when everything freezes and the various glitches are worked out.
OTOH there are some regressions you'll never see on a test box (network logins anyone ?) - so rawhide should be kept dogfoodable so the annoying bugs that take a long time to be fixed can be detected soon enough.
And yes that does mean the system will be hosed for ~ 1 day/month (except right after the release freeze where you'd be mad to do a sync). For some people that's a cheap price to have FC's work right after release and not a month later.
IMHO the tester is right we've passed the post-FC3 phase where it's ok to turn rawhide upside down and it's time to put it in a semi-testable state (this is by no means a demand, just my own POW - if Raw Hide can't be used before test releases it's little use for everyone, Red Hat included)
Regards,
On Mon, 31 Jan 2005 19:57:07 +0100, Nicolas Mailhot Nicolas.Mailhot@laposte.net wrote:
IMHO the tester is right we've passed the post-FC3 phase where it's ok to turn rawhide upside down and it's time to put it in a semi-testable state (this is by no means a demand, just my own POW - if Raw Hide can't be used before test releases it's little use for everyone, Red Hat included)
good thing the orignal poster filed a bug report then so this issue can be tracked accordingly.
Aren't we jumping to conclusions here about the maintainer's intent? A quick look at http://cvs.fedora.redhat.com/viewcvs/devel/evolution-connector/ tells me the connector codebase was updated when evolution was, meaning for some reason the rawhide build system isn't building the new evolution-connector updates. Wouldn't it be grand if a rawhide tester interested in helping resolve the issue would check out the cvs tree via anonymous cvs, try to rebuild the package for themselves... identify the problem that is preventing the nightly rawhide build... and report back via bugzilla.
Instead making rather unrealistic demands that packages in rawhide build flawlessly on the first attempt... how about we find a way to better communicate to rawhide users the build status of rawhide packages. Clearly, just having the cvs server up and accessible isn't cutting through the inertia. Perhaps if the daily rawhide summary reports also gave a list of packages that failed to build correctly... maybe that would be useful informations to rawhide testers... and inspire them to checkout cvs trees and attempt to identify and help resolve build issues with patches to bugzilla.
-jef"i wonder if a bug report as been filed while i write this"spaleta
Le lundi 31 janvier 2005 à 14:25 -0500, Jeff Spaleta a écrit :
On Mon, 31 Jan 2005 19:57:07 +0100, Nicolas Mailhot Nicolas.Mailhot@laposte.net wrote:
(this is by no means a demand, just my own POW - if Raw Hide can't be used before test releases it's little use for everyone, Red Hat included)
Instead making rather unrealistic demands that packages in rawhide build flawlessly on the first attempt...
Like I said, this is any sort of demand. Please do not put words that I explicitly refused to use in my mouth.
I was answering the assertion that " You can't expect real stability until the few weeks prior to release when everything freezes and the various glitches are worked out. If there was any mandate to keep Rawhide stable at all times, it would be the equivalent of production and they would have to put out Beta/RC releases for Rawhide! "
A "few weeks prior to release" is way too late to start worrying about stabilising Raw Hide. You know it and I know it. Therefore the first poster was perfectly right to expect the stabilisation to be under way by now (and to fill a bug). Presenting Raw Hide to be so dangerous you can not beta-test it is as counter-productive as expecting it to be perfect. It's more raw than FC, but with a little care it won't eat your brainz either (to quote a famous post on this list).
Regards,
On Mon, 31 Jan 2005 20:46:57 +0100, Nicolas Mailhot Nicolas.Mailhot@laposte.net wrote:
Like I said, this is any sort of demand. Please do not put words that I explicitly refused to use in my mouth.
sorry, i apologize.
A "few weeks prior to release" is way too late to start worrying about stabilising Raw Hide. You know it and I know it.
prior to which release? to test1? I know no such thing... in fact the oo.org 1.x versus 2.x pep-rally is still raging. I'd imagine if we applied nominal effort we can hijack that thread and grind that discussion to a halt while we debate the finer points as to which day in the development cycle stablization should turn a corner.
Hell.. i even expect to see some major shifts in tree content post-test1. If there are some very very dubious breakages in test1 that have no resolutions on the time scale of full release i fully expect to see some downgrades happening in test2. And packages downgrades are always fun in rawhide.. since there has never been any promise to make rawhide monotonically updatable via the use of epochs.
-jef
On the same note, when the new (2.9.x) panel for gnome was built, someone it seems forgot to reenable the eds stuff. I do use it.
Trever
On Mon, 2005-01-31 at 13:22 -0500, David Hollis wrote:
On Mon, 2005-01-31 at 10:11 -0600, Edginton, Brian (GE Healthcare) wrote:
I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward.
Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. So now in this test environment mail is completely useless.
Is there a way to encourage, or preferably enforce, keeping the wavefront coherent?
edge
If you have an important workstation/server, you really shouldn't be running from Rawhide. Things get out of sync, break, get your cat pregnant, etc. all the time. You can't expect real stability until the few weeks prior to release when everything freezes and the various glitches are worked out. If there was any mandate to keep Rawhide stable at all times, it would be the equivalent of production and they would have to put out Beta/RC releases for Rawhide! Then we'd never see anything go anywhere.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- "If there was strife and contention in the home, very little else in life could compensate for it." -- Lawana Blackwell, The Courtship of the Vicar's Daughter, 1998
On Mon, 2005-01-31 at 12:04 -0700, Trever L. Adams wrote:
On the same note, when the new (2.9.x) panel for gnome was built, someone it seems forgot to reenable the eds stuff. I do use it.
Actually it seems it was disabled intentionally, not sure why Jeremy did that, but it probably is a temporary fix for something.
https://www.redhat.com/archives/fedora-devel-list/2005-January/msg01717.html
On Mon, 2005-01-31 at 14:10 -0500, Bryan Clark wrote:
On Mon, 2005-01-31 at 12:04 -0700, Trever L. Adams wrote:
On the same note, when the new (2.9.x) panel for gnome was built, someone it seems forgot to reenable the eds stuff. I do use it.
Actually it seems it was disabled intentionally, not sure why Jeremy did that, but it probably is a temporary fix for something.
https://www.redhat.com/archives/fedora-devel-list/2005-January/msg01717.html
That was for gnome-panel 2.8 since it didn't know the API needed for newer e-d-s. 2.9.90-1 looks to me like it should be back enabled
Jeremy
On Mon, 2005-01-31 at 12:04 -0700, Trever L. Adams wrote:
On the same note, when the new (2.9.x) panel for gnome was built, someone it seems forgot to reenable the eds stuff. I do use it.
It looks like it should be enabled according to the spec file... that doesn't mean it's not broken though :-)
Jeremy
devel@lists.stg.fedoraproject.org
-
Bryan Clark -
David Hollis -
Edginton, Brian (GE Healthcare) -
Jef Spaleta -
Jeremy Katz -
Nicolas Mailhot -
Trever L. Adams