Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
If the infrastructure sucks where you live, what needs to happen is that the infrastructure needs to improve, not that the whole world adapts to stone-age infrastructure. Bandwidth is required for many more applications than just fetching Fedora updates.
That is just completely out of touch with reality. We live in the real world and have to deal with real problems; you can't just wave a magic wand and make them go away.
While many third-world countries have made high speed connections a priority, these countries are often densely populated. In more rural areas, high speed connections are economically impractical.
Here in Michigan, which is one of the more populous states, terrestrial high speed connections are simply unavailable in about half the state. Satellite connections are expensive, not terribly fast, and because of the weather, very unreliable.
Much of this state has a population density less than 5 people per square kilometer, and that is crowded compared to many of the western states. At those population densities it will be some time before technology will be able to deliver high bandwidth connections economically to much of the population.
If you are sitting in the crowded cities of western Europe, it may be hard to imagine a world where your nearest neighbor is a kilometer away, but that is how it is in much of the world. The distances can be vast, and hard to picture from inside Europe (or Manhattan, for that matter).
--McD
On Fri, Mar 12, 2010 at 5:32 PM, John J. McDonough wb8rcr@arrl.net wrote:
Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
If the infrastructure sucks where you live, what needs to happen is that the infrastructure needs to improve, not that the whole world adapts to stone-age infrastructure. Bandwidth is required for many more applications than just fetching Fedora updates.
That is just completely out of touch with reality. We live in the real world and have to deal with real problems; you can't just wave a magic wand and make them go away.
While many third-world countries have made high speed connections a priority, these countries are often densely populated. In more rural areas, high speed connections are economically impractical.
Here in Michigan, which is one of the more populous states, terrestrial high speed connections are simply unavailable in about half the state. Satellite connections are expensive, not terribly fast, and because of the weather, very unreliable.
Much of this state has a population density less than 5 people per square kilometer, and that is crowded compared to many of the western states. At those population densities it will be some time before technology will be able to deliver high bandwidth connections economically to much of the population.
If you are sitting in the crowded cities of western Europe, it may be hard to imagine a world where your nearest neighbor is a kilometer away, but that is how it is in much of the world. The distances can be vast, and hard to picture from inside Europe (or Manhattan, for that matter).
Hm.. Thank you for that post.
That was the first post who made me think different about the infra problem. I'm still not with the idea to change Fedora completely. But i think a compromise like N-1 as much as possible only security and bugfixes (from our bugzilla only, so it's clear *our* users face them). Includes to me no games with the kernel and other big packages of software. Kernel just security fixes in updates. Bugfix releases of the kernel either in a special repo for N-1 or from koji. Keep N as it is to satisfy the people who want it leading edge. Means the behavior as yet, except with autoQA testing and the other improvements already mentioned to prevent breakage as much as possible.
Rawhide the same as it is.
That should make anybody happy. People who expect Fedora as it is right now, stay with N and people with lower bandwidth, infra problems, can use N-1.
Could be started with F-13 release.
Thomas Janssen wrote:
That was the first post who made me think different about the infra problem. I'm still not with the idea to change Fedora completely. But i think a compromise like N-1 as much as possible only security and bugfixes (from our bugzilla only, so it's clear *our* users face them). Includes to me no games with the kernel and other big packages of software. Kernel just security fixes in updates. Bugfix releases of the kernel either in a special repo for N-1 or from koji. Keep N as it is to satisfy the people who want it leading edge. Means the behavior as yet, except with autoQA testing and the other improvements already mentioned to prevent breakage as much as possible.
Rawhide the same as it is.
That should make anybody happy. People who expect Fedora as it is right now, stay with N and people with lower bandwidth, infra problems, can use N-1.
Could be started with F-13 release.
The problem with all the proposals centered on the idea of N-1 as conservative, N as less conservative, including yours above and jreznik's, is that it forces all the people who expect a constant type of updates to upgrade twice as often, i.e. twice a year. Especially for the conservative folks, this will be a big annoyance. With low bandwidths, you have to get a CD/DVD shipped each time! In addition, I think the inconsistency will confuse our users a lot.
Kevin Kofler
On Fri, 12 Mar 2010 21:21:41 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem with all the proposals centered on the idea of N-1 as conservative, N as less conservative, including yours above and jreznik's, is that it forces all the people who expect a constant type of updates to upgrade twice as often, i.e. twice a year. Especially for the conservative folks, this will be a big annoyance. With low bandwidths, you have to get a CD/DVD shipped each time! In addition, I think the inconsistency will confuse our users a lot.
I think you have to decide if you are siding for people with low bandwidth or cutting them out. You just said we cannot cater to people with low bandwidth. Well stick with your point and don't swindle as soon as it doesn't help you win an argument for argument sake ...
Users are confused and annoyed by too frequent upgrades. Those people are fine sticking with N and then N-1 until security updates are no more, and only jumping from N-1 to N+1 once a year. This includes many developers I can assure you.
Simo.
Hello Simo,
Friday, March 12, 2010, 3:42:41 PM, you wrote:
On Fri, 12 Mar 2010 21:21:41 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem with all the proposals centered on the idea of N-1 as conservative, N as less conservative, including yours above and jreznik's, is that it forces all the people who expect a constant type of updates to upgrade twice as often, i.e. twice a year. Especially for the conservative folks, this will be a big annoyance. With low bandwidths, you have to get a CD/DVD shipped each time! In addition, I think the inconsistency will confuse our users a lot.
Fedora has traditionally supported upgrading from not just N-1, but also N-2. Folks often skip releases, especially if they are aware of problems (such as the pulseaudio and X issues) with a new release.
I think you have to decide if you are siding for people with low bandwidth or cutting them out. You just said we cannot cater to people with low bandwidth. Well stick with your point and don't swindle as soon as it doesn't help you win an argument for argument sake ...
Users are confused and annoyed by too frequent upgrades. Those people are fine sticking with N and then N-1 until security updates are no more, and only jumping from N-1 to N+1 once a year. This includes many developers I can assure you. Simo.
I've also run into cases where I tried to upgrade, but it failed to install. I restored from backups, and kept using the older release until I had time to do a fresh install. I do not believe my experience is unique.
Al Dunsmuir wrote:
On Fri, 12 Mar 2010 21:21:41 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem with all the proposals centered on the idea of N-1 as conservative, N as less conservative, including yours above and jreznik's, is that it forces all the people who expect a constant type of updates to upgrade twice as often, i.e. twice a year. Especially for the conservative folks, this will be a big annoyance. With low bandwidths, you have to get a CD/DVD shipped each time! In addition, I think the inconsistency will confuse our users a lot.
Fedora has traditionally supported upgrading from not just N-1, but also N-2. Folks often skip releases, especially if they are aware of problems (such as the pulseaudio and X issues) with a new release.
That's the whole point! People do this now, but having the two current releases be supported in a radically different way (with radically different update strategies) would make this no longer a viable option for many people.
Kevin Kofler
Hello Kevin,
Friday, March 12, 2010, 5:33:15 PM, you wrote:
Al Dunsmuir wrote:
On Fri, 12 Mar 2010 21:21:41 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem with all the proposals centered on the idea of N-1 as conservative, N as less conservative, including yours above and jreznik's, is that it forces all the people who expect a constant type of updates to upgrade twice as often, i.e. twice a year. Especially for the conservative folks, this will be a big annoyance. With low bandwidths, you have to get a CD/DVD shipped each time! In addition, I think the inconsistency will confuse our users a lot.
Fedora has traditionally supported upgrading from not just N-1, but also N-2. Folks often skip releases, especially if they are aware of problems (such as the pulseaudio and X issues) with a new release.
That's the whole point! People do this now, but having the two current releases be supported in a radically different way (with radically different update strategies) would make this no longer a viable option for many people. Kevin Kofler
One could argue that one a bit differently. Assuming the following releases: * N (upgrade target) current * N-1 less current than N by factor X * N-2 less current than N-1 by factor Y less current than N-2 by factor Z
Say Y is 3 times larger than X (1/3 of the equivalent updates).
You are going to point out that the user will see a very large change (Z) as they upgrade from N-2 to N. This may be a large transition, with significant learning and configuration involved. Keeping N-1 and N-2 close to N reduces that. No argument for that point.
What some of us are arguing is that the risk and cost (to the users in time, effort) for our user base increases as the release ages.
Slowing down the stream of updates that are for low priority bug fixes and new feature increases Y over X. It helps to keep the release more stable (same bugs/behaviour) for users at that release. Less updates on average means less chance of a regression. It also means those updates that do go out are likely better reviewed and tested.
One of the common problems with updates is where release N-1 or N-2 have a package at a newer level than the equivalent package on release N. This can easily happen due to differences in the propagation of updates to the various mirror, or if the release N package spends just a bit more time in updates-testing than the others, and misses a window to go to stable. The risk that this happening increases if one does final builds for a given fix simultaneously in multiple releases. Staggering the builds and doing N, then N-1, then N-2 with time to have users validate each minimizes that risk.
Different users are willing to accept different risks, but I would submit that a user running release N has demonstrated their willingness to risk the update. Users in release N-1 and N-2 have also demonstrated either their inability to update (bugs) or unwillingness to update. What some of us are proposing is that the updates for each release should reflect those demographics. Al
Al Dunsmuir wrote:
You are going to point out that the user will see a very large change (Z) as they upgrade from N-2 to N. This may be a large transition, with significant learning and configuration involved. Keeping N-1 and N-2 close to N reduces that. No argument for that point.
Huh? That was not my point at all! Please reread what I actually wrote! You are arguing against a strawman.
One of the common problems with updates is where release N-1 or N-2 have a package at a newer level than the equivalent package on release N. This can easily happen due to differences in the propagation of updates to the various mirror,
This is pretty much a non-issue. Mirroring delays are measured in hours at most.
or if the release N package spends just a bit more time in updates- testing than the others, and misses a window to go to stable.
That doesn't happen if the push to stable is requested by the maintainer for all releases at once (starting from the newest, in case you're worried about the push happening right in the few seconds between the requests for n and n+1 coming in). In fact that's the whole reason why I think we should consider testing together for all releases and not separately for each (the latter being what you proposed in a different thread).
Kevin Kofler
Simo Sorce wrote:
On Fri, 12 Mar 2010 21:21:41 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem with all the proposals centered on the idea of N-1 as conservative, N as less conservative, including yours above and jreznik's, is that it forces all the people who expect a constant type of updates to upgrade twice as often, i.e. twice a year. Especially for the conservative folks, this will be a big annoyance. With low bandwidths, you have to get a CD/DVD shipped each time! In addition, I think the inconsistency will confuse our users a lot.
I think you have to decide if you are siding for people with low bandwidth or cutting them out. You just said we cannot cater to people with low bandwidth. Well stick with your point and don't swindle as soon as it doesn't help you win an argument for argument sake ...
You don't understand my point! Please make sure you understood what the other person is saying before accusing them of hypocrisy!
Thomas Janssen is the one who proposed to cater to people with low bandwidth by making the N-1 release (and only the N-1 release, not the N release) less often updated. My argument is that this doesn't make sense because upgrading every 6 months will suck for those people (and also for other user groups who are asking for conservative updates).
Kevin Kofler
John J. McDonough wrote:
Much of this state has a population density less than 5 people per square kilometer, and that is crowded compared to many of the western states. At those population densities it will be some time before technology will be able to deliver high bandwidth connections economically to much of the population.
You have a good point there. I was in the Midwest (in Bowling Green, Ohio, to be precise) with my parents for 4 months in 2001 and indeed we've been surprised by the sparsity of population there.
But that still doesn't answer the question whether it shouldn't be up to people like you to choose a distribution catering to your needs as opposed to imposing them on the existing Fedora. The problem is, if all the distributions optimize for people with low bandwidth, then what should people like me who have higher bandwidths and would like to use their bandwidth to get current software use?
Kevin Kofler
On Fri, 12 Mar 2010 21:18:11 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem is, if all the distributions optimize for people with low bandwidth, then what should people like me who have higher bandwidths and would like to use their bandwidth to get current software use?
rawhide? F-13 ?
Simo.
Simo Sorce wrote:
On Fri, 12 Mar 2010 21:18:11 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem is, if all the distributions optimize for people with low bandwidth, then what should people like me who have higher bandwidths and would like to use their bandwidth to get current software use?
rawhide? F-13 ?
No.
This has already been explained several times!
Rawhide is not the answer. It comes with disruptive changes (and there's no real way to avoid this problem, see e.g. my replies to Doug Ledford's "To semi-rolling or not to semi-rolling, that is the question..." thread for details, but it has also been brought up in other threads), prereleases of software which is only expected to be stable at release time, no testing repository (so all the breakage gets dumped directly on the Rawhide user) etc.
The upcoming release branch is also not the answer. It is not available at all half of the time, and it is feature-frozen, so it doesn't actually get the expected feature upgrades (and with a policy like the one you appear to defend, it won't get them at all, not even after the release).
Kevin Kofler
Hello Kevin,
Friday, March 12, 2010, 5:39:33 PM, you wrote:
On Fri, 12 Mar 2010 21:18:11 +0100 Simo Sorce wrote: rawhide? F-13 ?
No.
This has already been explained several times!
Rawhide is not the answer. It comes with disruptive changes (and there's no real way to avoid this problem, see e.g. my replies to Doug Ledford's "To semi-rolling or not to semi-rolling, that is the question..." thread for details, but it has also been brought up in other threads), prereleases of software which is only expected to be stable at release time, no testing repository (so all the breakage gets dumped directly on the Rawhide user) etc.
The upcoming release branch is also not the answer. It is not available at all half of the time, and it is feature-frozen, so it doesn't actually get the expected feature upgrades (and with a policy like the one you appear to defend, it won't get them at all, not even after the release).
Kevin Kofler
Maybe part of the answer is that some resources (especially automation) need to be dedicated to keep the core critical components of rawhide from being gratuitously broken and staying that way?
If these core components were on average in better shape, that should mean that the other packages would tend to also be in better shape.
That way, instead of a massive "get rawhide branch working" effort spike, some of that effort could be used on an ongoing basis to keep the spike smaller - perhaps even containable, so there is a better chance that the branch works and the alpha doesn't slip so often or by so much.
Al
Al Dunsmuir wrote:
Maybe part of the answer is that some resources (especially automation) need to be dedicated to keep the core critical components of rawhide from being gratuitously broken and staying that way?
An answer to what question? Certainly not to the points I made!
The problem is not with gratuitous breakage, but with breakage inherent to a rolling branch such as Rawhide.
Kevin Kofler
Friday, March 12, 2010, 7:02:54 PM, Kevin wrote:
Al Dunsmuir wrote:
Maybe part of the answer is that some resources (especially automation) need to be dedicated to keep the core critical components of rawhide from being gratuitously broken and staying that way?
An answer to what question? Certainly not to the points I made!
The problem is not with gratuitous breakage, but with breakage inherent to a rolling branch such as Rawhide.
Kevin Kofler
And turning all releases into rolling branches helps keep things sane?
Please call a spade a spade. Without a reduction in churn in the stable releases that is what they become and remain until EOL - a rolling branch.
Al Dunsmuir wrote:
And turning all releases into rolling branches helps keep things sane?
Please call a spade a spade. Without a reduction in churn in the stable releases that is what they become and remain until EOL - a rolling branch.
No, a "semi-rolling" branch, as in a branch which picks up rolling feature upgrades WITHOUT the disruption and breakage inherent to a rolling branch, which instead only happens from one release to another. In other words, the best of both worlds (release-based and rolling).
Kevin Kofler
On 13/03/10 01:45, Kevin Kofler wrote:
Al Dunsmuir wrote:
And turning all releases into rolling branches helps keep things sane?
Please call a spade a spade. Without a reduction in churn in the stable releases that is what they become and remain until EOL - a rolling branch.
No, a "semi-rolling" branch, as in a branch which picks up rolling feature upgrades WITHOUT the disruption and breakage inherent to a rolling branch, which instead only happens from one release to another. In other words, the best of both worlds (release-based and rolling).
Kevin Kofler
It is generally "new features" that break things. The core part of a "stable" release is that it has a known set of features that users and developers can base their work on. This allows users to use the system and progress with their own work. Some people still predominately use Fedora rather than work on it.
The Fedora "stable" system has become more and more unstable I believe due to the move to more frontier "new features" and quicker almost untested updates. For an individual user most new features are of no benefit at all, some times they are a disadvantage.
Last night I was helping some school kids with a powerpoint presentation they had written. They had, not un-reasoanbly, used FontWork titles. Under F12 with OpenOffice 3.1 it took 3 minutes to load the 10 slide file and about 1 minute between slides. Editing was basically impossible. I had to go back to a F8 system OpenOffice 2.x system to edit the FontWork out. How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.
Fedora has to have some actual users otherwise there is no real testing done and no real developer/user communication.
I do think Rawhide is the place for real frontier work, but it seems to be moving more and more into stable. Maybe that is because more front end developers are working with Fedora and less users ?
Terry
Terry Barnaby wrote:
Last night I was helping some school kids with a powerpoint presentation they had written. They had, not un-reasoanbly, used FontWork titles. Under F12 with OpenOffice 3.1 it took 3 minutes to load the 10 slide file and about 1 minute between slides. Editing was basically impossible. I had to go back to a F8 system OpenOffice 2.x system to edit the FontWork out. How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.
OO.o 3.1 wasn't even an update, F12 shipped with it, so this is completely off topic here.
Kevin Kofler
On 14/03/10 16:29, Kevin Kofler wrote:
Terry Barnaby wrote:
Last night I was helping some school kids with a powerpoint presentation they had written. They had, not un-reasoanbly, used FontWork titles. Under F12 with OpenOffice 3.1 it took 3 minutes to load the 10 slide file and about 1 minute between slides. Editing was basically impossible. I had to go back to a F8 system OpenOffice 2.x system to edit the FontWork out. How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.
OO.o 3.1 wasn't even an update, F12 shipped with it, so this is completely off topic here.
Kevin Kofler
Yes, I guess this paragraph of my email, is a bit of topic, but I think still related. It is saying that even Fedora "releases" appear to have too little testing prior to release. The move to have less tested updates as well is moving even more in this direction in my eyes...
Terry Barnaby wrote:
Yes, I guess this paragraph of my email, is a bit of topic, but I think still related. It is saying that even Fedora "releases" appear to have too little testing prior to release. The move to have less tested updates as well is moving even more in this direction in my eyes...
I'm not moving to have "less tested" updates, but not to have "more tested" updates as updates are already sufficiently tested and the proposed ways to get more testing are all broken. (The only way we can actually get more testing is the obvious one: to have more testers.) I don't think ANYBODY here is moving for "less tested" updates!
Kevin Kofler
On Sat, Mar 13, 2010 at 07:58:03AM +0000, Terry Barnaby wrote:
Last night I was helping some school kids with a powerpoint presentation they had written. They had, not un-reasoanbly, used FontWork titles. Under F12 with OpenOffice 3.1 it took 3 minutes to load the 10 slide file and about 1 minute between slides. Editing was basically impossible. I had to go back to a F8 system OpenOffice 2.x system to edit the FontWork out. How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.
And where is your bug report? Anyway, there is no justification for you having used the wording that you used ('How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.'), because:
1. Fontwork objects are 3-D objects, therefore the performance depends on graphic driver, card and so on. I just checked it and it works reasonably well on my machine (6-slide presentation with a fontwork on each slide was loaded in 10 seconds and transition between slides took a second at worst). That means there are users for whom it works without problems.
2. This upstream bug: http://www.openoffice.org/issues/show_bug.cgi?id=58291 says someone had similar performance problems with fontwork in OO.o 2.0. That means it's nothing new in 3.1 (and I personally doubt there was much change in this area between 2.3 and 3.1).
3. Fontwork is just a very small piece of OO.o. Even if it had as poor performance as you describe on _every_ system, it would hardly be a blocker for release of OO.o and it's absolutely unimaginable it would be a blocker for release of Fedora. That means it can hardly be described as basic issue.
D.
On 03/18/2010 06:28 AM, David Tardon wrote:
On Sat, Mar 13, 2010 at 07:58:03AM +0000, Terry Barnaby wrote:
Last night I was helping some school kids with a powerpoint presentation they had written. They had, not un-reasoanbly, used FontWork titles. Under F12 with OpenOffice 3.1 it took 3 minutes to load the 10 slide file and about 1 minute between slides. Editing was basically impossible. I had to go back to a F8 system OpenOffice 2.x system to edit the FontWork out. How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.
And where is your bug report? Anyway, there is no justification for you having used the wording that you used ('How on earth did this "release" get out (Fedora/OpenOffice ??) ?? This is just one of many basic issues I and others have had with Fedora recently.'), because:
Fontwork objects are 3-D objects, therefore the performance depends on graphic driver, card and so on. I just checked it and it works reasonably well on my machine (6-slide presentation with a fontwork on each slide was loaded in 10 seconds and transition between slides took a second at worst). That means there are users for whom it works without problems.
This upstream bug: http://www.openoffice.org/issues/show_bug.cgi?id=58291 says someone had similar performance problems with fontwork in OO.o 2.0. That means it's nothing new in 3.1 (and I personally doubt there was much change in this area between 2.3 and 3.1).
Fontwork is just a very small piece of OO.o. Even if it had as poor performance as you describe on _every_ system, it would hardly be a blocker for release of OO.o and it's absolutely unimaginable it would be a blocker for release of Fedora. That means it can hardly be described as basic issue.
D.
Ok, the wording is a bit strong but Fedora 12 has let me down on quite a number of occasions when doing, what I would call, basic user tasks. It actually failed in the actual presentation as a video would not display on the projector connected to the laptop (black window).
No bug report as yet, I'm not sure which area is at fault. I suspect an issue with the ATI graphics driver, Mesa, libdrm, Kernel DRM, X-Server or its interaction with OpenOffice as Fedora12 has many many issues with graphics. (X-Server and OpenOffice at close to 100% CPU during delay). I tried it on 3 different systems all had the same issues. In the end I went back to Fedora 8 with OpenOffice 2.3 and it worked fine (on the same hardware). I have filed quite a few bug reports on Graphics and other issues already, but have had little response. I will try and do so but I am more and more feeling it may be a waste of time ... I have said on numerous occasions that a serious look at the Graphics issues needs to be undertaken. I think a lot of the core issues people are having are due to bugs in this area ...
Fontwork may be a small part of OpenOffice and I personally haven't used it. It is however a fairly well known and commonly used feature. Certainly my and other kids use it at school extensively.
As part of a Fedora release I would have thought that part of the test schedule would be to load and view some test documents with openoffice on a set number of platforms (Different graphics chipsets). This would likely have picked this up ...
Cheers
Terry
On 03/18/2010 06:27 PM, Terry Barnaby wrote:
As part of a Fedora release I would have thought that part of the test schedule would be to load and view some test documents with openoffice on a set number of platforms (Different graphics chipsets). This would likely have picked this up ...
With the current list of major new features, the test days don't cover anything like this. If you are interested and want to volunteer, that would be very helpful.
Rahul
On 03/18/2010 12:58 PM, Rahul Sundaram wrote:
On 03/18/2010 06:27 PM, Terry Barnaby wrote:
As part of a Fedora release I would have thought that part of the test schedule would be to load and view some test documents with openoffice on a set number of platforms (Different graphics chipsets). This would likely have picked this up ...
With the current list of major new features, the test days don't cover anything like this. If you are interested and want to volunteer, that would be very helpful.
Rahul
Although I am willing to help test, and have taken part in Fedora testing days, I personally feel that the current apparent climate in Fedora (frequent releases, pushing new features fast and perhaps now pushing updates more quickly) will make testing difficult and stability difficult to achieve and very hard work. I'm not sure I want to use significant amounts of my time battling that ....
On 03/18/2010 07:56 PM, Terry Barnaby wrote:
Although I am willing to help test, and have taken part in Fedora testing days, I personally feel that the current apparent climate in Fedora (frequent releases, pushing new features fast and perhaps now pushing updates more quickly) will make testing difficult and stability difficult to achieve and very hard work. I'm not sure I want to use significant amounts of my time battling that ....
You are conflating two different although related things. Test days are focussed on testing the features in the development branch so that the general release is of good quality. Update strategy will not affect it in any way although it seems you have missed out Fedora Board's and FESCo's proposals on update policies. If that is the case, refer to
https://fedoraproject.org/wiki/Stable_release_updates_vision
Bill Nottingham's proposal to FESCo at
https://fedorahosted.org/fesco/ticket/351
If you are willing to help, you should coordinate with the QA team on that but to have realistic expectations, such a feature in Openoffice.org would not be a blocker for either OO.o upstream or a Fedora release at any time. Finding out regressions is useful nevertheless. We can document them better.
Rahul
On Thu, 2010-03-18 at 18:28 +0530, Rahul Sundaram wrote:
On 03/18/2010 06:27 PM, Terry Barnaby wrote:
As part of a Fedora release I would have thought that part of the test schedule would be to load and view some test documents with openoffice on a set number of platforms (Different graphics chipsets). This would likely have picked this up ...
With the current list of major new features, the test days don't cover anything like this. If you are interested and want to volunteer, that would be very helpful.
Indeed. We haven't done an OO.o Test Day lately (possibly we never have). No-one's ever proposed one, and no-one in QA uses OO.o at all extensively (I use it maybe once a month, to write simple letters for mailing), so we haven't really had the necessary knowledge base to run one ourselves.
If you / others who actually use OO.o extensively would like to propose an OO.o Test Day, we'd certainly be happy to add it to the schedule and help you organize it.
On Thu, 2010-03-18 at 12:57 +0000, Terry Barnaby wrote:
As part of a Fedora release I would have thought that part of the test schedule would be to load and view some test documents with openoffice on a set number of platforms (Different graphics chipsets). This would likely have picked this up ...
Ahh. Idealism. :)
No, we are nowhere near this. We only implemented any kind of desktop testing for the F13 cycle. Prior to F13, there was no planned validation testing of anything besides the installer.
More generally, we consider it acceptable to release Fedora with known regressions in functionality where this is ultimately required to drive development forward. QA and devel groups know very well that some AMD/ATI adapters behave worse in F10 onwards than they did in F9 and earlier (though they tend to be better in F13 than F12, and better in F12 than F11). This is due to extensive architecture changes in the driver which were considered necessary to support new and future hardware properly, and implement new models like Gallium.
On 18/03/10 19:18, Adam Williamson wrote:
On Thu, 2010-03-18 at 12:57 +0000, Terry Barnaby wrote:
As part of a Fedora release I would have thought that part of the test schedule would be to load and view some test documents with openoffice on a set number of platforms (Different graphics chipsets). This would likely have picked this up ...
Ahh. Idealism. :)
No, we are nowhere near this. We only implemented any kind of desktop testing for the F13 cycle. Prior to F13, there was no planned validation testing of anything besides the installer.
More generally, we consider it acceptable to release Fedora with known regressions in functionality where this is ultimately required to drive development forward. QA and devel groups know very well that some AMD/ATI adapters behave worse in F10 onwards than they did in F9 and earlier (though they tend to be better in F13 than F12, and better in F12 than F11). This is due to extensive architecture changes in the driver which were considered necessary to support new and future hardware properly, and implement new models like Gallium.
Although I understand Fedora's frontier status, I think the graphics system changes could probably have been handled better. After the kernel and core shared libraries the graphics system is probably the next essential core OS subsystem (At least for desktop systems). It seems most of peoples stability issues with fedora stem from graphics. I do understand the difficulty with the multitude of different graphics chipsets out there. But this is where Fedora could shine with its close links to upstream development. It would have been good to be very upfront with this and get a group to define and setup some basic graphics tests and loudly promote users to perform tests with these both pre-release and post-release. This with a website with test status versus graphics board/chipsets and with good easy linkages to Bugzilla (more user friendly) and perhaps a separate graphics-testing repository to keep quick graphics updates away from the "stable" release etc. If enough upstream developers, Fedora packagers and testing users were in on this I think great inroads into getting stable and good graphics systems would be made in a relatively short time.
Some more Idealism :)
On Thu, 2010-03-18 at 20:47 +0000, Terry Barnaby wrote:
Although I understand Fedora's frontier status, I think the graphics system changes could probably have been handled better. After the kernel and core shared libraries the graphics system is probably the next essential core OS subsystem (At least for desktop systems). It seems most of peoples stability issues with fedora stem from graphics. I do understand the difficulty with the multitude of different graphics chipsets out there. But this is where Fedora could shine with its close links to upstream development. It would have been good to be very upfront with this and get a group to define and setup some basic graphics tests and loudly promote users to perform tests with these both pre-release and post-release.
We've done this, since F11, with the Graphics Test Days. They get a very large response. That's mostly how we know what's broken.
This with a website with test status versus graphics board/chipsets and with good easy linkages to Bugzilla (more user friendly)
https://fedoraproject.org/wiki/Test_Day:2009-09-09_Radeon#Results https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau#Results https://fedoraproject.org/wiki/Test_Day:2009-09-11_Intel#Results
and perhaps a separate graphics-testing repository to keep quick graphics updates away from the "stable" release etc.
This would likely do more harm than good by increasing developer overhead and making everyone very confused about exactly what anyone was running...
If enough upstream developers, Fedora packagers and testing users were in on this I think great inroads into getting stable and good graphics systems would be made in a relatively short time.
That's somewhat optimistic; no matter how much testing we do, we can only afford a certain amount of full-time developer muscle. The testing has helped to improve efficiency and direction of graphics development work, I think, but there's fundamentally a lot of work to do and only a limited amount of manpower to do it with.
The X devs are always very happy to take new volunteers. :)
On 03/18/2010 09:00 PM, Adam Williamson wrote:
......... That's somewhat optimistic; no matter how much testing we do, we can only afford a certain amount of full-time developer muscle. The testing has helped to improve efficiency and direction of graphics development work, I think, but there's fundamentally a lot of work to do and only a limited amount of manpower to do it with.
The X devs are always very happy to take new volunteers. :)
Although I have done a fair amount of X development work in the past, unfortunately, as with most people, my volunteer time is in short supply (I have a wife and kids to support :) ). So "in use" testing, bug reporting and attempting the first pass bug searches is currently my limit in Fedora.
If there were less churn in Fedora to cope with perhaps I and other user/developers would have more unpaid volunteer time to devote to actual development :)
Terry Barnaby wrote:
Although I understand Fedora's frontier status, I think the graphics system changes could probably have been handled better. After the kernel and core shared libraries the graphics system is probably the next essential core OS subsystem (At least for desktop systems). It seems most of peoples stability issues with fedora stem from graphics. I do understand the difficulty with the multitude of different graphics chipsets out there. But this is where Fedora could shine with its close links to upstream development. It would have been good to be very upfront with this and get a group to define and setup some basic graphics tests and loudly promote users to perform tests with these both pre-release and post-release. This with a website with test status versus graphics board/chipsets and with good easy linkages to Bugzilla (more user friendly) and perhaps a separate graphics-testing repository to keep quick graphics updates away from the "stable" release etc. If enough upstream developers, Fedora packagers and testing users were in on this I think great inroads into getting stable and good graphics systems would be made in a relatively short time.
Unfortunately, a sizeable portion of our users installs some crappy proprietary driver, sometimes not even a properly packaged one, but using some broken installation script directly from the hardware vendor's website, making this all moot. :-( While it is true that our Free drivers are far from perfect as well, most graphics-related problems are actually due to proprietary drivers. Just say NO to proprietary drivers! (And in fact this is one of the reasons why our drivers are a bit on the experimental side, it's needed to get support for as much hardware as possible with our Free drivers, e.g. there's now experimental 3D support for Nouveau in F13.)
Kevin Kofler
On Sat, 2010-03-20 at 07:14 +0100, Kevin Kofler wrote:
Terry Barnaby wrote:
Although I understand Fedora's frontier status, I think the graphics system changes could probably have been handled better. After the kernel and core shared libraries the graphics system is probably the next essential core OS subsystem (At least for desktop systems). It seems most of peoples stability issues with fedora stem from graphics. I do understand the difficulty with the multitude of different graphics chipsets out there. But this is where Fedora could shine with its close links to upstream development. It would have been good to be very upfront with this and get a group to define and setup some basic graphics tests and loudly promote users to perform tests with these both pre-release and post-release. This with a website with test status versus graphics board/chipsets and with good easy linkages to Bugzilla (more user friendly) and perhaps a separate graphics-testing repository to keep quick graphics updates away from the "stable" release etc. If enough upstream developers, Fedora packagers and testing users were in on this I think great inroads into getting stable and good graphics systems would be made in a relatively short time.
Unfortunately, a sizeable portion of our users installs some crappy proprietary driver, sometimes not even a properly packaged one, but using some broken installation script directly from the hardware vendor's website, making this all moot. :-( While it is true that our Free drivers are far from perfect as well, most graphics-related problems are actually due to proprietary drivers. Just say NO to proprietary drivers!
This isn't really true. Or at least, not a productive perspective for improving Fedora. There are certainly a lot of bugs in the open drivers shipped with Fedora, and there's a lot of work to do to fix them all. I sent my own reply to Terry explaining how we're handling this at present, but just waving the 'it's all NVIDIA's fault' stick at the problem won't make it go away :)
This isn't really true. Or at least, not a productive perspective for improving Fedora. There are certainly a lot of bugs in the open drivers shipped with Fedora, and there's a lot of work to do to fix them all. I sent my own reply to Terry explaining how we're handling this at present, but just waving the 'it's all NVIDIA's fault' stick at the problem won't make it go away :)
One little point I noticed recently. I was watching and testing a package released by Fedora. I was having some email conversations with some of the upstream developers of that package at the time.
From what I noticed, there did not seem to be much communication between
the Fedora packagers and the upstream developers. Particularly the upstream developers appeared to be unaware that their code had been packaged for Fedora/Redhat etc. In fact they were looking at creating a binary release and looking at how to test it on various platforms.
I don't know if this is an isolated case, but if it is common maybe:
1. The upstream developers email addresses or mailing list could be added to an email list on the package in the FedoraBuild system. 2. When a package is submitted for testing then an email and possibly other communications is made between the packager and the upstream developers with the suggestion that the package has been built for testing. 3. All RPM fixes required are emailed back to upstream developers.
It seems to me that it would be good if the upstream developers knew of the package and were encouraged to test it. They are most likely to find any initial obvious issues.
Cheers
Terry
On 03/26/2010 09:43 PM, Terry Barnaby wrote:
This isn't really true. Or at least, not a productive perspective for improving Fedora. There are certainly a lot of bugs in the open drivers shipped with Fedora, and there's a lot of work to do to fix them all. I sent my own reply to Terry explaining how we're handling this at present, but just waving the 'it's all NVIDIA's fault' stick at the problem won't make it go away :)
One little point I noticed recently. I was watching and testing a package released by Fedora. I was having some email conversations with some of the upstream developers of that package at the time.
From what I noticed, there did not seem to be much communication between
the Fedora packagers and the upstream developers.
That is unlikely to be the general case. You seem to be extrapolating from a single instance. Fedora on the whole has a policy to work closely with upstream.
http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Inform...
I sometimes forget as well and not surprised there would be instances where upstream is not informed.
Rahul
On Fri, Mar 26, 2010 at 09:55:19PM +0530, Rahul Sundaram wrote:
http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Inform...
I sometimes forget as well and not surprised there would be instances where upstream is not informed.
You added the section about informing upstream about half a year ago, therefore I guess the majority of package maintainer did not do this. I know I never did this, unless they already list other distributions or I had to send a patch.
Regards Till
On 03/26/2010 10:26 PM, Till Maas wrote:
On Fri, Mar 26, 2010 at 09:55:19PM +0530, Rahul Sundaram wrote:
http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Inform...
I sometimes forget as well and not surprised there would be instances where upstream is not informed.
You added the section about informing upstream about half a year ago, therefore I guess the majority of package maintainer did not do this. I know I never did this, unless they already list other distributions or I had to send a patch.
I had assumed that it would be a obvious thing to do before that. Isn't that the case?
Rahul
* Till Maas [26/03/2010 18:00] :
You added the section about informing upstream about half a year ago, therefore I guess the majority of package maintainer did not do this. I know I never did this, unless they already list other distributions or I had to send a patch.
I've always done this (although I suppose a number of packages have fallen through the cracks), even before that section was there.
Interestingly enough, the first upstream I informed replied that I was the first packager to do so despite the fact that his work was already featured in a number of distributions.
Emmanuel
On Fri, 2010-03-26 at 16:13 +0000, Terry Barnaby wrote:
This isn't really true. Or at least, not a productive perspective for improving Fedora. There are certainly a lot of bugs in the open drivers shipped with Fedora, and there's a lot of work to do to fix them all. I sent my own reply to Terry explaining how we're handling this at present, but just waving the 'it's all NVIDIA's fault' stick at the problem won't make it go away :)
One little point I noticed recently. I was watching and testing a package released by Fedora. I was having some email conversations with some of the upstream developers of that package at the time.
From what I noticed, there did not seem to be much communication between the Fedora packagers and the upstream developers. Particularly the upstream developers appeared to be unaware that their code had been packaged for Fedora/Redhat etc. In fact they were looking at creating a binary release and looking at how to test it on various platforms.
I don't know if this is an isolated case, but if it is common maybe:
Not in the case of graphics, no. In most cases, the 'upstream developers' and Fedora packagers, as far as X.org goes, are the same people. Where this isn't the case, they're in very close contact.
On Fri, 2010-03-12 at 23:39 +0100, Kevin Kofler wrote:
Simo Sorce wrote:
On Fri, 12 Mar 2010 21:18:11 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem is, if all the distributions optimize for people with low bandwidth, then what should people like me who have higher bandwidths and would like to use their bandwidth to get current software use?
rawhide? F-13 ?
No.
Yes.
Rawhide is not the answer.
<pantomime>Oh yes it is</pantomime>
It comes with disruptive changes
So does F12 today. I have a desktop here I've been logged into for 2 weeks and I daren't run an update on it for fear something is going to break. I don't know that something is going to break, just that the last few times I did an update I had to reboot and fix something afterward, and it invariably took more than a few minutes to get back to where I started. I will update over the weekend, and I'm expecting something to break. Conversely, I expect my rawhide installs to break each day and they have actually been more stable recently than my F12 updates!
Kevin, it sounds like you're mostly concerned with KDE. Do you have an objection to the rest of F12 critical path stuff being left alone so I can rely on my GNOME desktop, with my printer, displays, etc. just working as they do today if I update tomorrow? If you don't, and if you're mostly concerned about KDE, then please say so. I don't have a huge objection (tongue in cheek jokes aside) if KDE updates every day :)
Jon.
On Fri, 12 Mar 2010 23:39:33 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
Simo Sorce wrote:
On Fri, 12 Mar 2010 21:18:11 +0100 Kevin Kofler kevin.kofler@chello.at wrote:
The problem is, if all the distributions optimize for people with low bandwidth, then what should people like me who have higher bandwidths and would like to use their bandwidth to get current software use?
rawhide? F-13 ?
No.
This has already been explained several times!
Rawhide is not the answer. It comes with disruptive changes (and there's no real way to avoid this problem, see e.g. my replies to Doug Ledford's "To semi-rolling or not to semi-rolling, that is the question..." thread for details, but it has also been brought up in other threads), prereleases of software which is only expected to be stable at release time, no testing repository (so all the breakage gets dumped directly on the Rawhide user) etc.
The upcoming release branch is also not the answer. It is not available at all half of the time, and it is feature-frozen, so it doesn't actually get the expected feature upgrades (and with a policy like the one you appear to defend, it won't get them at all, not even after the release).
I seriously think you have a problem understanding the difference between development and release and what is the purpose of a release.
I understand and wholly reject your point, and I don't think you have any data to show most of the user that choose to use a release over rawhide want the kind of rolling release you want.
As far as I can see all you want a slightly-stabler-rawhide, that's not what a release is.
Simo.
-
Adam Williamson -
Al Dunsmuir -
David Tardon -
Emmanuel Seyman -
John J. McDonough -
Jon Masters -
Kevin Kofler -
Rahul Sundaram -
Simo Sorce -
Terry Barnaby -
Thomas Janssen -
Till Maas