One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
-- Rex
On 03/08/2010 08:26 AM, Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
-- Rex
Hi,
In paper, well in this times, in the wiki conservative updates seems a great idea, in practice not so much.
I'm a Fedora user, because, the latest or almost latest version of Linux (unix/cli programs) and KDE latest,
maybe change "to limit kde 4.x-type upgrades to at most 1 per release" to "stop kde 4.x-type upgrades one month before the Release of next Fedora version."
because the former suppose which Fedora will not have a long development cycle and kde cannot have two (major versions) shorter ones.
but if the above scenario occurs, by example:
- One month from Fedora Release, KDE release a major version. - Four months later KDE release a new major version - The next Fedora has delays - result Fedora current cannot upgrade to the latest kde because the guidelines say so.
having not the latest KDE in the latest Fedora Release, well that will be a point where I will consider migrate to another distribution. considering the following scenario:
backporting is a con, not a benefit, kde is really huge to try to backporting fixes, well in the sense laid in the proposal and that will break the "releases close to the upstream ships"
if you have a stable kde in Fedora N-1 why take the risk of backporting fixes not done by upstream (besides security fixes), I mean risk of introducing new code, source of potentially new bugs.
in my opinion leave kde in Fedora N-1, alone besides major bugs happening,
Not which I didn't found bugs or breaking something in kde with my computers, but all were fixables.
If I need working with the computer with a timeline, I don't update until having time to dedicate, because the risk of breakage.
So as a Fedora user the current policy fits my needs, I only hope which the new one meets them too.
Gabriel
P.D. I'm not like conservative aproach because sometimes that is translate if something don't work right at release shipping time and only is fixed in major version of software, the software aren't updated
case in point: xorg intel driver in F11 version 7.X -random freezes with desktop effects enabled solution by upstream update to version 8.X of the drivers solution by policy desactivate the desktop effects the 7.X drivers stays in F11
my solution rebuilding the 8.X rpm from rawhide under mock, after that I have KDE running with desktop effects enabled in F11 without crashes.
P.D.-2 I have many more problems with PulseAudio, sometimes PA works beautifully , and sometimes wants to have a rest :) , and I did'nt see yet the proposal to bring back ALSA and dmix meanwhile PulseAudio is developed to a working state, and this isn't against PulseAudio itself I use it, but if a new update policy is developed I doubt PA meets the standard to release.
On 03/08/2010 12:34 PM, Gabriel Ramirez wrote:
I'm a Fedora user, because, the latest or almost latest version of Linux (unix/cli programs) and KDE latest,
As things currently stand with fedora and kde release cycles, this will never happen.
With this proposal, the latest fedora will still be eligible for the latest kde release. What changes is that Fcurrent-1 likely won't get it.
-- Rex
On Monday 08 March 2010 21:10:14 Petrus de Calguarium wrote:
Rex Dieter wrote:
Stability_Proposal
There hasn't been any significant instability, so to propose stability doesn't make sense ;-)
Some people are more sensitive and even small change can confuse them. Some people would take really big change... This is more than stability proposal, compromise proposal - you will get one "stable and conservative" release and of course one "not as stable/aggressive" release. Stable in terms for example UI changes etc., not talking about breaking something.
Jaroslav
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Mon, Mar 8, 2010 at 8:26 AM, Rex Dieter rdieter@math.unl.edu wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
What will that mean for people like myself looking for little bug fixes? Also, what is meant to be the goal of this slow down? Is it too much work for the Fedora KDE devs? If so I would be for it. Otherwise, I'm quite happy with stability as far as Fedora is concerned.
On 03/08/2010 02:46 PM, Arthur Pemberton wrote:
What will that mean for people like myself looking for little bug fixes?
To be clear: This proposal is only about kde 4.x => kde 4.(x+1) style updates.
(little) bugfixes as well as bugfix-only kde releases like kde-4.x.y => kde-4.x.(y+1) are all still fair game any time.
-- Rex
On Mon, Mar 8, 2010 at 2:52 PM, Rex Dieter rdieter@math.unl.edu wrote:
On 03/08/2010 02:46 PM, Arthur Pemberton wrote:
What will that mean for people like myself looking for little bug fixes?
To be clear: This proposal is only about kde 4.x => kde 4.(x+1) style updates.
(little) bugfixes as well as bugfix-only kde releases like kde-4.x.y => kde-4.x.(y+1) are all still fair game any time.
I understand that, but some bug fixes seem to wait around till those 4.(x+1) releases like the recent task bar problems
On Monday 08 March 2010 21:46:38 Arthur Pemberton wrote:
On Mon, Mar 8, 2010 at 8:26 AM, Rex Dieter rdieter@math.unl.edu wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
What will that mean for people like myself looking for little bug fixes?
Great opportunity for junior developers to backport/fix small issues ;-)
Also, what is meant to be the goal of this slow down? Is it too much work for the Fedora KDE devs? If so I would be for it. Otherwise, I'm quite happy with stability as far as Fedora is concerned.
It can lead even to more work - as for example backport of some security issue. I've explained it in previous mail, check this thread - this is compromise.
Jaroslav
On Tue, Mar 9, 2010 at 3:44 AM, Jaroslav Reznik jreznik@redhat.com wrote:
On Monday 08 March 2010 21:46:38 Arthur Pemberton wrote:
On Mon, Mar 8, 2010 at 8:26 AM, Rex Dieter rdieter@math.unl.edu wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
What will that mean for people like myself looking for little bug fixes?
Great opportunity for junior developers to backport/fix small issues ;-)
So then this may actually involve more work? I like Fedora's fast pace (though recently slowing) nature. I'd be happy to endorse this if it meant less work for the KDE team.
On 03/09/2010 11:07 AM, Arthur Pemberton wrote:
So then this may actually involve more work? I like Fedora's fast pace (though recently slowing) nature. I'd be happy to endorse this if it meant less work for the KDE team.
Yup, stability + bug fixes takes work. Hopefully as part of the KDE project as whole, not just packagers.
On Mon 8 March 2010 7:26:30 am Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
Will this proposal apply to kde-redhat and rawhide as well?
On 03/08/2010 02:51 PM, Ryan Rix wrote:
On Mon 8 March 2010 7:26:30 am Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
Will this proposal apply to kde-redhat and rawhide as well?
No. It applies only to kde-4.x => kde-4.x+1 updates to already released fedoras.
-- Rex
On Mon 8 March 2010 2:05:51 pm Rex Dieter wrote:
No. It applies only to kde-4.x => kde-4.x+1 updates to already released fedoras.
Then I am in favor of this update policy.
Ryan
On 3/8/2010 7:26 AM, Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
-- Rex
I'm in favor of the proposal (I'd even argue for less updates...). However, I think it would be important to lobby upstream for more bug fix releases or some other method for distributions to more easily consume bug fixes into released packages.
- Orion
On 8 March 2010 14:26, Rex Dieter rdieter@math.unl.edu wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
-- Rex
Bad News
...dex
Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
Considering the results of Adam Williamson's poll of Fedora users and considering how I still don't see a reason why we'd treat the previous stable release any differently than the current stable (there is no such policy anywhere in Fedora, it's just pointless second-class treatment), I'm still very much against this proposal.
If the update is good enough to be stable for F12, why is it not good enough for F11 as well? As for workload, the things which are the most work (bumping the specfile, removing obsolete patches, occasionally fixing file lists, making sure it builds) have to be done anyway, building the same stuff one more time is basically trivial anyway.
I really see no benefit whatsoever in not upgrading the previous stable Fedora, and instead I see major drawbacks (no more bugfixes, except for possibly select few backported ones (but there's no way we can backport all of them!); additional workload for us because we can no longer just sync the specfile to fix issues; etc.).
Kevin Kofler
On 09/03/10 01:11, Kevin Kofler wrote:
Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
Considering the results of Adam Williamson's poll of Fedora users and considering how I still don't see a reason why we'd treat the previous stable release any differently than the current stable (there is no such policy anywhere in Fedora, it's just pointless second-class treatment), I'm still very much against this proposal.
Although I'm not sure how representative of the whole community the poll is, I'd like to strongly agree with Kevin here. In the research group I support we usually upgrade to every other Fedora release, and having the previous to current release less well supported in the KDE department would be poor for us.
If the update is good enough to be stable for F12, why is it not good enough for F11 as well? As for workload, the things which are the most work (bumping the specfile, removing obsolete patches, occasionally fixing file lists, making sure it builds) have to be done anyway, building the same stuff one more time is basically trivial anyway.
Many comments in various threads seem to have picked up on the 'reduce the workload for the KDE team' idea. The current system works very well, it minimizes the work for the KDE team, and keeps all supported Fedora release as well supported as possible given the available effort. I dont see a need to change it.
I really see no benefit whatsoever in not upgrading the previous stable Fedora, and instead I see major drawbacks (no more bugfixes, except for possibly select few backported ones (but there's no way we can backport all of them!); additional workload for us because we can no longer just sync the specfile to fix issues; etc.).
Agreed.
What I think some people don't like is any change to the desktop or new bugs getting introduced with major new features. However Fedora is known and has as one of its underpinning principles to 'lead' rather than 'follow', so I'd hope that just being rather more explicit in the documentation (somewhere) about what the updates system for KDE is would go a very long way to resolve this issue. After all the KDE team are fantastically responsive to issues.
In summary, the system as it is seems to work very well for us, and it looks to me as if it also minimizes the work for the KDE group.
If I were to be able to vote, I'd vote to keep the updates system as it is.
Roderick
On 03/10/2010 04:44 AM, Roderick Johnstone wrote:
What I think some people don't like is any change to the desktop or new bugs getting introduced with major new features. However Fedora is known and has as one of its underpinning principles to 'lead' rather than 'follow', so I'd hope that just being rather more explicit in the documentation (somewhere) about what the updates system for KDE is would go a very long way to resolve this issue. After all the KDE team are fantastically responsive to issues.
I don't necessarily disagree with this, or the other reservations about the new proposal. But I would add that it would be helpful if people had a better idea how they could "lock down" certain apps, or even if that were possible. I.e., prevent certain things from upgrading. Allowing a user to say, well, I'm just not going to upgrade KDE has to be a good thing. Of course, you can do that now, but it is too complicated, and it is too easy to mess up, get the upgrade, and then have to go through some nightmarish process to roll it back.
Richard
On Tuesday 09 March 2010 02:11:52 Kevin Kofler wrote:
Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
Considering the results of Adam Williamson's poll of Fedora users and considering how I still don't see a reason why we'd treat the previous stable release any differently than the current stable (there is no such policy anywhere in Fedora, it's just pointless second-class treatment), I'm still very much against this proposal.
If the update is good enough to be stable for F12, why is it not good enough for F11 as well? As for workload, the things which are the most work (bumping the specfile, removing obsolete patches, occasionally fixing file lists, making sure it builds) have to be done anyway, building the same stuff one more time is basically trivial anyway.
It's not only about stability as crashes, regression etc. but also about stability in terms of same UI. So yes - if we can deliver working crash/regression stable update to F12, we can for sure do the same for F11. But for some people even small UI changes are big changes. You would probably argue that RHEL/CentOS is for these users but it's not actually true - these distros are not very well suited for desktop usage (hw support is big issue for example). And Ubuntu is just crap ;-)
Jaroslav
I really see no benefit whatsoever in not upgrading the previous stable Fedora, and instead I see major drawbacks (no more bugfixes, except for possibly select few backported ones (but there's no way we can backport all of them!); additional workload for us because we can no longer just sync the specfile to fix issues; etc.).
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Jaroslav Reznik wrote:
It's not only about stability as crashes, regression etc. but also about stability in terms of same UI.
This is not something we want or can deliver in Fedora.
It's not like the UIs are radically changing. From one KDE release series to the next, they're vastly the same.
So yes - if we can deliver working crash/regression stable update to F12, we can for sure do the same for F11. But for some people even small UI changes are big changes. You would probably argue that RHEL/CentOS is for these users but it's not actually true - these distros are not very well suited for desktop usage (hw support is big issue for example). And Ubuntu is just crap ;-)
But those distros are really the only good option.
Using the previous stable Fedora is not a viable solution for these people. It only has 7 months of support as "previous stable". That means that to always be on "previous stable", you have to upgrade twice a year. There goes the "UI stability". So trying to target the previous stable release at those people is a losing proposition anyway. Those folks need something with a lot more than 7 months of support.
Kevin Kofler
On Wed, Mar 10, 2010 at 11:33 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Jaroslav Reznik wrote:
It's not only about stability as crashes, regression etc. but also about stability in terms of same UI.
This is not something we want or can deliver in Fedora.
It's not like the UIs are radically changing. From one KDE release series to the next, they're vastly the same.
Well, i think one example some users wasn't happy with a UI change is the Add Widget UI.
On Wednesday 10 March 2010 23:33:20 Kevin Kofler wrote:
Jaroslav Reznik wrote:
It's not only about stability as crashes, regression etc. but also about stability in terms of same UI.
This is not something we want or can deliver in Fedora.
It's not like the UIs are radically changing. From one KDE release series to the next, they're vastly the same.
So yes - if we can deliver working crash/regression stable update to F12, we can for sure do the same for F11. But for some people even small UI changes are big changes. You would probably argue that RHEL/CentOS is for these users but it's not actually true - these distros are not very well suited for desktop usage (hw support is big issue for example). And Ubuntu is just crap ;-)
But those distros are really the only good option.
Using the previous stable Fedora is not a viable solution for these people. It only has 7 months of support as "previous stable". That means that to always be on "previous stable", you have to upgrade twice a year. There goes the "UI stability". So trying to target the previous stable release at those people is a losing proposition anyway. Those folks need something with a lot more than 7 months of support.
That's the conflict in others proposal - they want conservative updates that breaks every 6 month (and 1 year max) by really big changes... Our changes while we're updating are not so terrible :( "Previous stable" needs prolonged support for this release (but it's out of scope of KDE SIG - that's why I'd like to have it done on whole disto basis).
Jaroslav
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
For the most part, I don't think the proposal will make much of a difference. The problem lies mostly with development practices over at KDE and not necessarily with the KDE packaging team at Fedora.
What really needs to happen, in my humble opinion, is that the packaging team needs to get together with the packaging team from the other distros and simply refuse to even consider package for testing until the current array of application bugs get fixed and that the QA upstream improves. There is no good reason why packaging teams need to take the flack for bad code.
While getting the eye candy to work is a nice added bonus, if we can't work with applications like Konqueror or the required Akonadi and are forced to (even on a temporary bases) too use non KDE apps then whats the point of KDE. Please do not misunderstand this as a call to dump, on the contrary, that most of the stuff in KDE works and that many of the added features make a big difference to the usability of KDE and indicates a great deal of skill and quality of code is amazing and worthy of respect and accolades. However, when something breaks, it really is very noticable. Its important for the developers to realize that people are relying on KDE and KDE apps to get things dones for work and pleasure otherwise. Otherwise the User will simply use something else.
Eli
On Monday 08 March 2010 16:26:30 Rex Dieter wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Whatever we decide, increasing our transparency by documenting our update practices will hopefully help shape everyone''s plans and expectations. As it is, seems these vary wildly.
-- Rex
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Eli Wapniarski wrote:
people are relying on KDE and KDE apps to get things done for work and pleasure
IMO, fedora is a 'cutting edge' distro and it is the testing ground for red hat. fedora is a wonderful 'gift' and I dread (!!!) the day they might decide to pull the plug and make us all pay :-( at the present, our bug reports are our means of payment to help them make red hat a better product.
fedora has always been excellent and the quality of the work is of the highest standard (try any other distro for even an hour to see what I mean) and the integration of the latest available updates is smooth and with barely a glitch, and then only briefly, at most a night (and this has only occurred twice in at least 2 years! once it was an Xorg issue to do with modesetting, the other time sesame2 vs virtuoso confusion).
People who expect never to encounter a bug, or who cannot afford to encounter a bug (pretty well impossible in a testing ground, and any work- or play-stopping ones have been fixed the following morning, or sooner, if one looks on koji or follows the bugzilla thread) should be using red hat, not fedora.
Petrus... with all due respect. It's not that I expect to have things completely bug free and as has been pointed out to me quite often is that Fedora is an independant distro in its own right.
While Fedora is bleeding edge, it is not a Beta Testing Ground for the software the KDE releases as stable only to find that in fact its Beta released to the public so that we can prepare the ground for stable.1. There have been a lot of bugs that I've reported for Konqueror that have existed in 3.x and have never been fixed. KDEPim 4.4.0 release was close to being a disaster. People have been a great deal of discussion regarding KDENetwork Manager, I've got still have issues with PulseAudio. Useabiltiy issues with the panel that are not going to be even looked at.
I need to emphasize this. These are not packaging issues. These are programming issues. And quite frankly I'm quite bored with the deification of the programmer who thinks that he's "all that"
Correct me if I'm wrong, but OpenSource is a collaborative effort. And part of the effort comes from users. And those users need to be confident that an upgrade to their system isn't going to destroy years of data gathering (backups not withstanding). And if I as a user want to visit CNN and click on a flash video in Konqueror, I don't expect my browser to crash. I expect it to show the the video. However, Konqueror crashes while using khtml or webkit far to often. However Chrome with webkit works brilliantly, but it isn't a KDE app. Nor is firefox. And again..... If I need to start using Gnome apps for regular day to day stuff. Why have the extra KDE libraries loaded. Excuse me.... I can live without the eye candy if it means my browser won't crash. But if my browser crashes I will have a much more difficult time getting the information I need to navigate my personal and professional world on a day to day basis but gee doesn't my desktop look great..... I've got wobbly windows.... whoopie.
Eli
On Tuesday 09 March 2010 19:19:56 Petrus de Calguarium wrote:
Eli Wapniarski wrote:
people are relying on KDE and KDE apps to get things done for work and pleasure
IMO, fedora is a 'cutting edge' distro and it is the testing ground for red hat. fedora is a wonderful 'gift' and I dread (!!!) the day they might decide to pull the plug and make us all pay
:-( at the present, our bug reports are our means
of payment to help them make red hat a better product.
fedora has always been excellent and the quality of the work is of the highest standard (try any other distro for even an hour to see what I mean) and the integration of the latest available updates is smooth and with barely a glitch, and then only briefly, at most a night (and this has only occurred twice in at least 2 years! once it was an Xorg issue to do with modesetting, the other time sesame2 vs virtuoso confusion).
People who expect never to encounter a bug, or who cannot afford to encounter a bug (pretty well impossible in a testing ground, and any work- or play-stopping ones have been fixed the following morning, or sooner, if one looks on koji or follows the bugzilla thread) should be using red hat, not fedora.
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Tuesday 09 March 2010 20:24:17 Kevin Kofler wrote:
Eli Wapniarski wrote:
And if I as a user want to visit CNN and click on a flash video in Konqueror, I don't expect my browser to crash.
The Flash plugin is not produced by KDE nor Fedora, we have no control over it.
Yet every other browser seems to work just fine with it
Eli
Eli Wapniarski wrote:
Eli
I sympathize with your exasperation. I am a longtime fedora and foss consumer and fedora tester -- when I am not so stubborn as not to submit a bug report ;-)
It appears to me that your concerns are ones regarding software programming, not regarding packaging.
It seems that the ball is now rolling. Hopefully, it will roll in such a way as to satisfy all our needs and expectations.
Personally, I had hoped that new packages/releases would end up in updates-testing sooner, circumventing kde-redhat, but, if I understand all that has been written recently, there will still be kde-redhat for the newest releases, and also, as I upgrade to the latest release the day it comes out -- usually as soon as the alpha comes out, so I will likely still be accessing the latest as soon as it becomes available.
If things end up moving too slowly, there will likely be a packager somewhere who will set up a new repo, so all is not lost. Hopefully, fedora will remain that packager, as it would be best to keep things under one hood for compatibility's sake (remember what it was like when Dag was packaging, too, and the conflict nightmare we went through?).
Kevin.... Forgive me.... Stubbornly sticking to a philosophy and code that clearly does not work well... is self defeating....And I care enough about KDE and Fedora to packages and a couple of apps. To provide what assistance I can as time permits. To monitor (not as closely as I would like) the discussions that go on in this mailing list and to try in my poor way to motivate positive changes if I feel their is a need to.
Developers of websites care about browsers in this order.
1) Ineternet Explorer 2) Firefox 3) Everything Else.
And its usually up to everyone else to do what needs to be done to get their browser to work otherwise people can't use it, even if they want to. Konqueror is capable of using webkit as its main rendering engine. Chrome uses webkit. Chrome works, KDE based aps don't. Hell their are times when I've tried to access pages on KDE's site and have seen Konqueror crash.
So forgive what might be my ignorance and the rhetorical question..... Hey after so many years of crashing and the occaissional rendering issue... What Gives??
Eli
On Wednesday 10 March 2010 01:36:17 Kevin Kofler wrote:
Eli Wapniarski wrote:
Yet every other browser seems to work just fine with it
Adobe doesn't give a darn about Konqueror. The Konqueror developers are already doing what they can to make it work. But ultimately, proprietary software cannot be relied on.
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Wednesday 10 March 2010 05:24:05 Eli Wapniarski wrote:
And its usually up to everyone else to do what needs to be done to get their browser to work otherwise people can't use it, even if they want to. Konqueror is capable of using webkit as its main rendering engine. Chrome uses webkit. Chrome works, KDE based aps don't. Hell their are times when I've tried to access pages on KDE's site and have seen Konqueror crash.
FWIW one of the reasons given for chrome to use a separate process for each tab was that if flash crashes then the browser will not be taken with.
So the idea that flash crashes in other browsers other than konqueror is not a new one. :-)
So forgive what might be my ignorance and the rhetorical question..... Hey after so many years of crashing and the occaissional rendering issue... What Gives??
Eli
Quoting José Matos jamatos@fc.up.pt:
On Wednesday 10 March 2010 05:24:05 Eli Wapniarski wrote:
And its usually up to everyone else to do what needs to be done to get their browser to work otherwise people can't use it, even if they want to. Konqueror is capable of using webkit as its main rendering engine. Chrome uses webkit. Chrome works, KDE based aps don't. Hell their are times when I've tried to access pages on KDE's site and have seen Konqueror crash.
FWIW one of the reasons given for chrome to use a separate process for each tab was that if flash crashes then the browser will not be taken with.
So the idea that flash crashes in other browsers other than konqueror is not a new one. :-)
Perhaps not, but it still doesn't take anything away from the fact that under Chrome / Webkit the browser does not crash when I try to view flash videos in CNN and other sites; under Konqueror / Webkit it does. They're both Webkit. So..... huh ??????
Eli
On Wednesday 10 March 2010 15:09:30 Eli Wapniarski wrote:
Quoting José Matos jamatos@fc.up.pt:
On Wednesday 10 March 2010 05:24:05 Eli Wapniarski wrote:
And its usually up to everyone else to do what needs to be done to get their browser to work otherwise people can't use it, even if they want to. Konqueror is capable of using webkit as its main rendering engine. Chrome uses webkit. Chrome works, KDE based aps don't. Hell their are times when I've tried to access pages on KDE's site and have seen Konqueror crash.
FWIW one of the reasons given for chrome to use a separate process for each tab was that if flash crashes then the browser will not be taken with.
So the idea that flash crashes in other browsers other than konqueror is not a new one. :-)
Perhaps not, but it still doesn't take anything away from the fact that under Chrome / Webkit the browser does not crash when I try to view flash videos in CNN and other sites; under Konqueror / Webkit it does. They're both Webkit. So..... huh ??????
It's not WebKit as WebKit... Konqueror uses QtWebKit and lot of stuff is different to Chrome WebKit. Especially handling of non native ns plugins like Flash.
Jaroslav
Eli
So essentially what this means is that Konqueror becomes less and less relevant. A real shame.
Eli
On Wednesday 10 March 2010 17:31:10 Jaroslav Reznik wrote:
On Wednesday 10 March 2010 15:09:30 Eli Wapniarski wrote:
Quoting José Matos jamatos@fc.up.pt:
On Wednesday 10 March 2010 05:24:05 Eli Wapniarski wrote:
And its usually up to everyone else to do what needs to be done to get their browser to work otherwise people can't use it, even if they want to. Konqueror is capable of using webkit as its main rendering engine. Chrome uses webkit. Chrome works, KDE based aps don't. Hell their are times when I've tried to access pages on KDE's site and have seen Konqueror crash.
FWIW one of the reasons given for chrome to use a separate process for each tab was that if flash crashes then the browser will not be taken with.
So the idea that flash crashes in other browsers other than konqueror is not a new one. :-)
Perhaps not, but it still doesn't take anything away from the fact that under Chrome / Webkit the browser does not crash when I try to view flash videos in CNN and other sites; under Konqueror / Webkit it does. They're both Webkit. So..... huh ??????
It's not WebKit as WebKit... Konqueror uses QtWebKit and lot of stuff is different to Chrome WebKit. Especially handling of non native ns plugins like Flash.
Jaroslav
Eli
For me it was. It was a great browser. Lightening fast and did just about everything that I needed it to do. Multimedia, Flash, etc....
Eli
On Wednesday 10 March 2010 19:52:54 Patrick Boutilier wrote:
On 03/10/2010 01:39 PM, Eli Wapniarski wrote:
So essentially what this means is that Konqueror becomes less and less relevant. A real shame.
Was it ever relevant? :-)
(other than as a file manager)
Eli
<snip> _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Eli Wapniarski wrote:
For me it was. It was a great browser. Lightening fast and did just about everything that I needed it to do. Multimedia, Flash, etc....
For me it still is. But I don't use Flash. I have gnash-klash installed instead, but I could live entirely without Flash as well.
Kevin Kofler
On Thursday 11 March 2010 00:39:27 Kevin Kofler wrote:
Eli Wapniarski wrote:
For me it was. It was a great browser. Lightening fast and did just about everything that I needed it to do. Multimedia, Flash, etc....
For me it still is. But I don't use Flash. I have gnash-klash installed instead, but I could live entirely without Flash as well.
Kevin Kofler
I've look into Gnash every once in awhile,and it has made tremendous progress, but its still not quite there. Looking forward to the time that it works with all the Websites I visit
Eli
On Wednesday 10 March 2010 19:11:38 Eli Wapniarski wrote:
For me it was. It was a great browser. Lightening fast and did just about everything that I needed it to do. Multimedia, Flash, etc....
Eli
Keep an eye on rekonq. It's making fast progress and I hope to prepare the update / package of the new version (0.4) this weekend, as soon as it's been released. I think they got caught up in a small delay, it should have been released this Tuesday.
Here's a the changelog of the features included in 0.4:
* moved to kdewebkit (this means based on kde 4.4) * kwallet support * KIO full support (cookies, cache, proxy, network) * file: & ftp: protocol easy handling * improved rekonq pages (in the about: protocol) * multithreaded url resolver (hopefully, no more UI freezes) * adblock support, first part (load manually links, for now...) * improved fullscreen mode * embedded inspector (A-LA firebug) * first kget integration * optional "clickToFlash" feature * tons of bugs fixed * ... (wanna more??)
Their plan is to become the default browser for KDE by version 0.6. Chakra even made it their default browser already. :)
Eelko Berkenpies wrote:
- KIO full support (cookies, cache, proxy, network)
Does kio_gopher work? :-)
And does it support KParts such as the OkularPart?
Their plan is to become the default browser for KDE by version 0.6.
But that doesn't depend only on them. Several people think it shouldn't be the default app as long as they insist on not using a menu bar, and I'd tend to agree with them. Somewhat relatedly, it's also missing many of Konqueror's features (which is why they can get away with no menu bar). (Plus, I don't see what's wrong with Konqueror and KHTML, IMHO QtWebKit and kdewebkit are reinventing the wheel.)
Kevin Kofler
On Thursday 11 March 2010 13:57:22 Kevin Kofler wrote:
Eelko Berkenpies wrote:
- KIO full support (cookies, cache, proxy, network)
Does kio_gopher work? :-)
And does it support KParts such as the OkularPart?
Their plan is to become the default browser for KDE by version 0.6.
But that doesn't depend only on them. Several people think it shouldn't be the default app as long as they insist on not using a menu bar, and I'd tend to agree with them.
For consistency it's bad when one app hides menu and other do not. But I'm the one who hides menu everywhere ;-)
Jaroslav
Somewhat relatedly, it's also missing many of Konqueror's features (which is why they can get away with no menu bar). (Plus, I don't see what's wrong with Konqueror and KHTML, IMHO QtWebKit and kdewebkit are reinventing the wheel.)
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Wednesday 10 March 2010 18:11:38 Eli Wapniarski wrote:
For me it was. It was a great browser. Lightening fast and did just about everything that I needed it to do. Multimedia, Flash, etc....
Strange - I could never use it for any on-line shopping - it always failed at the checkout.
Anne
On Wed, Mar 10, 2010 at 9:31 AM, Jaroslav Reznik jreznik@redhat.com wrote:
It's not WebKit as WebKit... Konqueror uses QtWebKit
When did this happen?
Arthur Pemberton wrote:
On Wed, Mar 10, 2010 at 9:31 AM, Jaroslav Reznik jreznik@redhat.com wrote:
It's not WebKit as WebKit... Konqueror uses QtWebKit
When did this happen?
There's now the WebKitPart which can be used in Konqueror. See the "View / View Mode" menu.
But the default rendering engine is NOT QtWebKit, it's still KHTML!
Kevin Kofler
On Wednesday 10 March 2010 23:37:26 Kevin Kofler wrote:
Arthur Pemberton wrote:
On Wed, Mar 10, 2010 at 9:31 AM, Jaroslav Reznik
jreznik@redhat.com wrote:
It's not WebKit as WebKit... Konqueror uses QtWebKit
When did this happen?
There's now the WebKitPart which can be used in Konqueror. See the "View / View Mode" menu.
But the default rendering engine is NOT QtWebKit, it's still KHTML!
Yes, of course! I wasn't accurate - I thought WebKitPart is QtWebKitBased! And QtWebKit != WebKit as found in Chromium != WebKit as found in Safari etc...
Jaroslav
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Eli Wapniarski wrote:
Perhaps not, but it still doesn't take anything away from the fact that under Chrome / Webkit the browser does not crash when I try to view flash videos in CNN and other sites; under Konqueror / Webkit it does. They're both Webkit. So..... huh ??????
Are you sure you're using WebKit? The default (and recommended) rendering engine in Konqueror is KHTML, not WebKit.
Kevin Kofler
On Thursday 11 March 2010 00:38:23 Kevin Kofler wrote:
Eli Wapniarski wrote:
Perhaps not, but it still doesn't take anything away from the fact that under Chrome / Webkit the browser does not crash when I try to view flash videos in CNN and other sites; under Konqueror / Webkit it does. They're both Webkit. So..... huh ??????
Are you sure you're using WebKit? The default (and recommended) rendering engine in Konqueror is KHTML, not WebKit.
Kevin Kofler
I've used both rendering engines.
Eli
On Wed, Mar 10, 2010 at 11:38 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Eli Wapniarski wrote:
Perhaps not, but it still doesn't take anything away from the fact that under Chrome / Webkit the browser does not crash when I try to view flash videos in CNN and other sites; under Konqueror / Webkit it does. They're both Webkit. So..... huh ??????
Are you sure you're using WebKit? The default (and recommended) rendering engine in Konqueror is KHTML, not WebKit.
I'm curious since i heard it a few times now from you. Who recommends it as the default rendering engine? It seems users do recommend WebKit as the default engine since it works better with e.g. gmail.
On Wed 10 March 2010 11:58:47 pm Thomas Janssen wrote:
I'm curious since i heard it a few times now from you. Who recommends it as the default rendering engine? It seems users do recommend WebKit as the default engine since it works better with e.g. gmail.
KDE ships it by default, do they not? Isn't that the "ultimate" recommendation? :)
Ryan
2010/3/11 Ryan Rix ry@n.rix.si:
On Wed 10 March 2010 11:58:47 pm Thomas Janssen wrote:
I'm curious since i heard it a few times now from you. Who recommends it as the default rendering engine? It seems users do recommend WebKit as the default engine since it works better with e.g. gmail.
KDE ships it by default, do they not? Isn't that the "ultimate" recommendation? :)
Yes, they ship it by default. Do we *recommend* the xine backend over the gstreamer backend just because we ship the xine one by default?
On Thu, Mar 11, 2010 at 1:59 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Thomas Janssen wrote:
Yes, they ship it by default. Do we *recommend* the xine backend over the gstreamer backend just because we ship the xine one by default?
Yes, we wouldn't make it the default otherwise!
I'm not sure if that's true. I was in the meetings of our SIG and it was decided that we ship the xine-backend by default. But i never read a single line about we *recommending* xine. It was that both had their pluses and minus and IIRC a voting made the xine the default for now. And everything looks like that the gstreamer-backend will be the default in the near future.
Doesn't sound like we really recommend it. So, what i was telling was, just because it's shipped by default, doesn't mean automatically it is recommended. IMO.
On 03/08/2010 10:55 PM, Eli Wapniarski wrote:
For the most part, I don't think the proposal will make much of a difference. The problem lies mostly with development practices over at KDE and not necessarily with the KDE packaging team at Fedora.
What really needs to happen, in my humble opinion, is that the packaging team needs to get together with the packaging team from the other distros and simply refuse to even consider package for testing until the current array of application bugs get fixed and that the QA upstream improves. There is no good reason why packaging teams need to take the flack for bad code.
I'm really starting to feel that this is the crux of the issue. So where do we go to start influencing KDE?
On 03/09/2010 11:36 AM, Orion Poplawski wrote:
On 03/08/2010 10:55 PM, Eli Wapniarski wrote:
What really needs to happen, in my humble opinion, is that the packaging team needs to get together with the packaging team from the other distros and simply refuse to even consider package for testing until the current array of application bugs get fixed and that the QA upstream improves. There is no good reason why packaging teams need to take the flack for bad code.
I'm really starting to feel that this is the crux of the issue. So where do we go to start influencing KDE?
hmmm, well maybe the solution is ship software with version > 4.x.1 only skiping 4.x.0 and 4.x.1.
so only others distributions will ship 4.x.0 and 4.x.1 not Fedora
but the above will not fix anything, only thing will happen is which the versions 4.x.2 will have the same quantity of bugs which the 4.x.0 and 4.x.1 in the present
the problem cause is not enough users test the updates before released in fedora,
so when the packagers review the decision to push a stable update, the bug list is short and no showstoppers are known
the long list of bugs is built after by the users which care to report bugs. and only after the release of the updates.
so meanwhile the users don't test the updates to be, the situation will be same. now Fedora ships Virtualization software, so the excuse to not testing the "updates to be" in the own computer, well install them in a Virtual Machine and test them.
Gabriel
On Mon, Mar 8, 2010 at 8:26 AM, Rex Dieter rdieter@math.unl.edu wrote:
One more call for discussion around another proposal that came out of FUDCon Toronto. Short version of this is that we'd consider slowing down updates a step, esp for the second half of a fedora release's lifetime, and to limit kde 4.x-type upgrades to at most 1 per release.
Just to go through the points
More time for developers to work on making the current release stable and to work on the latest and greatest for Rawhide
Is there any middle ground between rawhide and updates?
Lets users know in advance what to expect during a release cycle.
I'm don't understand how this change would accomplish that
Will encourage users who want the latest and greatest to stay current with the Fedora releases.
Maybe I'm failing to comprehend this goal, but wanting the latest and greatest seems contrary to the RFC's goal
Will create some low hanging fruit in the way of backporting specific fixes into the older releases. These will be some good junior jobs that can be showcased to get new people onboard the KDE SIG, or to provide those already in the SIG but who are maybe not packagers a way to help.
I guess I should have read properly before asking my previous question. Is creating new work really a goal to actively pursue?
KDE updates often also need an updated Qt; for example updating to KDE 4.4 means that Qt has to be updated to 4.6. As more and more applications are written with Qt, pushing out Qt updates to older Fedora branches might destabilize a lot of non-KDE apps (or at least create maintainer burden).
I understand the issue here. Though I don't agree that a Fedora-KDE based RFC should concern itself with this. This is Fedora, software is expected to be very up to date.
-
Anne Wilson -
Arthur Pemberton -
Charles Zeitler -
dexter -
Eelko Berkenpies -
Eli Wapniarski -
Gabriel Ramirez -
Jaroslav Reznik -
José Abílio Matos -
Kevin Kofler -
Orion Poplawski -
Patrick Boutilier -
Petrus de Calguarium -
Rex Dieter -
Richard Heck -
Roderick Johnstone -
Ryan Rix -
Thomas Janssen