Ironically it happened again, just now when these FESCO threads are still warm.
My desktop gui processes leak enough mem that I need to restart couple times a week or system will run out of memory. Today I started with updating the F11 with yum. During the update, I noticed that it's pulling in the kde-4.4.0, scary. Then reboot.
Now when I logged in, noticed that desktop has really changed quite a bit, some visual stuff even fixed.
Then I tried to start kmail to start working. It starts, asks passwords, whines something about Akonadi which i don't use and then crashes/exists.
kmail(4465)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on "local:/tmp/ksocket-tuju/kmailRj4465.slave-socket" kmail(4465)/libakonadi Akonadi::Control::Private::exec: Could not start/stop Akonadi! kmail(4465) main: Unable to start Akonadi server, exit application kmail(4465)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: (gdb)
This is exactly kind off stuff I don't have time now to solve, since I need to work. If such upgrade would have been put to next coming release, I could have upgraded when I have time, some weekend - it would not interrupted my working and ruin my day.
For all those who say that "latest stuff is the reason why I use Fedora!!!1", there is rawhide for you.
For a lot of people, this kind of breakage is exactly the reason not to switch from windows/mac to Fedora.
Yes, I'm writing this with Alpine... handling pdf attachments and doing invoicing with it is going to be fun.
KDE SIG, you need to re-think that proposal again.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
On Thu, 4 Mar 2010, Juha Tuomala wrote:
Then I tried to start kmail to start working. It starts, asks passwords, whines something about Akonadi which i don't use and then crashes/exists.
Not to mention that kaddressbook which contains all my business contacts, is broken too:
http://tuju.fi/fedora/11/kab-20100304.png
looks like that some icons are also missing, but hard to judge as it wont start properly to interact with user.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
On Thursday 04 March 2010 13:05:36 Juha Tuomala wrote:
On Thu, 4 Mar 2010, Juha Tuomala wrote:
Then I tried to start kmail to start working. It starts, asks passwords, whines something about Akonadi which i don't use and then crashes/exists.
Not to mention that kaddressbook which contains all my business contacts, is broken too:
http://tuju.fi/fedora/11/kab-20100304.png
looks like that some icons are also missing, but hard to judge as it wont start properly to interact with user.
That's the problem of not running Akonadi - it's central PIM part of KDE. Could you try to run it manually and paste log/output somewhere?
akonadictl start
Thanks
Tuju
-- Ajatteleva ihminen tarvitsee unta.
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
http://tuju.fi/fedora/11/kab-20100304.png
looks like that some icons are also missing, but hard to judge as it wont start properly to interact with user.
That's the problem of not running Akonadi - it's central PIM part of KDE.
The funny part is that Akonadi is still very much a work in progress. I've tried to get it working many times without success. That's the reason majority still uses those plain resources.
Few days back I asked Rex, 'Do you use Akonadi, or know anyone who does?' - He repiled that he doesn't. (please correct me if I'm wrong). I've asked quite many others too, which say that they don't use it. It's unmature. It would be interesting to know, how many KDE SIG members actually use it? :)
I've talked to one who works for living with KDE PIM stuff, with Akonadi people and he says that they are very unsatisfied to its backends and it's still evolving a lot. They are actually moving from mysqld to http://virtuoso.openlinksw.com/ (already used in nepomuk, so KDE drags two RDMBS to desktop atm - funny.)
I get that this is now being pushed down the throat at KDE side and they probably think that it might get better with wider testing base and thus they make the code depend hard on it. Fine, and they did it in their *feature release* since even they don't think that it's insane to enforce people in the middle of their workweek to become betatesters of some unfinished project.
If we only could get KDE SIG to start thinking like their upstream have intended them to think, lot of people wouldn't be in this mess right now.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
Juha Tuomala wrote:
The funny part is that Akonadi is still very much a work in progress. I've tried to get it working many times without success. That's the reason majority still uses those plain resources.
Uh, Akonadi is now always used for contacts as of KDE 4.4.
Few days back I asked Rex, 'Do you use Akonadi, or know anyone who does?' - He repiled that he doesn't. (please correct me if I'm wrong). I've asked quite many others too, which say that they don't use it. It's unmature. It would be interesting to know, how many KDE SIG members actually use it? :)
Uh, all of us who use kdepim apps now use it for contacts. We don't use it for anything else, but that's part of upstream's Akonadi migration plan. In 4.5, all PIM data will be in Akonadi. Akonadi-based versions of all the PIM apps have already been merged into KDE's SVN trunk.
I've talked to one who works for living with KDE PIM stuff, with Akonadi people and he says that they are very unsatisfied to its backends and it's still evolving a lot. They are actually moving from mysqld to http://virtuoso.openlinksw.com/ (already used in nepomuk, so KDE drags two RDMBS to desktop atm - funny.)
Virtuoso is actually not a traditional RDBMS. It's a semantic (RDF/SparQL) database built on top of a relational (SQL) core. As the relational part is there anyway, they also allow you to access it directly, so Virtuoso can also be used as an RDBMS, and this is what Akonadi is planning to do, so they can share the database server with Nepomuk, which uses Virtuoso for its RDF functionality. But even if the default changes, the MySQL backend is not going away, it will be needed at least to convert existing data from 4.4.
I get that this is now being pushed down the throat at KDE side and they probably think that it might get better with wider testing base and thus they make the code depend hard on it. Fine, and they did it in their *feature release* since even they don't think that it's insane to enforce people in the middle of their workweek to become betatesters of some unfinished project.
If we only could get KDE SIG to start thinking like their upstream have intended them to think, lot of people wouldn't be in this mess right now.
Upstream has no policy about what kind of releases are to be provided as updates, this is a distribution decision.
Kevin Kofler
On Thu, 4 Mar 2010, Kevin Kofler wrote:
Upstream has no policy about what kind of releases are to be provided as updates, this is a distribution decision.
They add features to own releases just for that reason, so downstreams and users could avoid such mess that has just happened.
If you don't understand that, you're part of the problem.
On Thu, 4 Mar 2010, Kevin Kofler wrote:
Nobody intentionally BREAKS things. Upstream KDE releases are supposed to be backwards compatible,
See, you used word 'supposed'. You've been around enough to know that reality is something else what you keep so passionately talking about.
Tuju
-- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
Could you try to run it manually and paste log/output somewhere?
akonadictl start
Was it so that mysqld wants to communicate through fs sockets which does not work on NFS $HOME?
[akonadiserver] Failed to use database "akonadi" [akonadiserver] Database error: "Can't connect to local MySQL server through socket '/home/tuju/.local/share/akonadi/db_misc/mysql.socket' (111) QMYSQL: Unable to connect"
Back then I have talked about this NFS issue with KDE SIG at #fedora-kde so many times that this cannot be the problem, since it wouldn't have been pushed into production when it was tested with NFS, right? :)
Tuju
-- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating
Juha Tuomala wrote:
Was it so that mysqld wants to communicate through fs sockets which does not work on NFS $HOME?
[akonadiserver] Failed to use database "akonadi" [akonadiserver] Database error: "Can't connect to local MySQL server [through socket '/home/tuju/.local/share/akonadi/db_misc/mysql.socket' (111) QMYSQL: Unable to connect"
Back then I have talked about this NFS issue with KDE SIG at #fedora-kde so many times that this cannot be the problem, since it wouldn't have been pushed into production when it was tested with NFS, right? :)
From what I can read on the web, Akonadi is supposed to work on NFS these
days. If it doesn't work, it's either: * some security framework blocking the access (I've found bug reports due to AppArmor in my search). On Fedora, the only possible offender would be SELinux. Please check for SELinux AVC denials in the logs and/or try disabling SELinux. But I don't think that's the issue. * your NFS server being broken and not supporting the required functionality, in which case this is not a Fedora issue.
An easy workaround if you always use the same machine is to move .local/share/akonadi to some local directory and symlink it from the NFS home directory.
Kevin Kofler
On 03/04/2010 05:13 PM, Juha Tuomala wrote:
This is exactly kind off stuff I don't have time now to solve, since I need to work. If such upgrade would have been put to next coming release, I could have upgraded when I have time, some weekend - it would not interrupted my working and ruin my day.
Yes and it does happen now and then that updates like these cause end users some pain and while some users love to tinker and play with new features others see it as a hindrance even if it is purely enhancement with no regressions because even UI changes cause disruption in workflow setting aside all the possibility of regressions and I dont believe that Fedora has the right balance between innovation and stability (not merely robustness but any change for that matter) at the moment (CentOS is far removed and rawhide is far too bleeding edge)
Whether it would be a separate backports repo or merely some more conservativeness in our update stream needs to be discussed and the current discussion has brought up very polarised opinions and at this point it would be useful to discuss detailed proposals than continuously repeating the same points in a circle
For your specific case please file bug reports
Rahul
On Thursday 04 March 2010 13:13:18 Rahul Sundaram wrote:
On 03/04/2010 05:13 PM, Juha Tuomala wrote:
This is exactly kind off stuff I don't have time now to solve, since I need to work. If such upgrade would have been put to next coming release, I could have upgraded when I have time, some weekend - it would not interrupted my working and ruin my day.
Yes and it does happen now and then that updates like these cause end users some pain and while some users love to tinker and play with new features others see it as a hindrance even if it is purely enhancement with no regressions because even UI changes cause disruption in workflow setting aside all the possibility of regressions and I dont believe that Fedora has the right balance between innovation and stability (not merely robustness but any change for that matter) at the moment (CentOS is far removed and rawhide is far too bleeding edge)
Whether it would be a separate backports repo or merely some more conservativeness in our update stream needs to be discussed and the current discussion has brought up very polarised opinions and at this point it would be useful to discuss detailed proposals than continuously repeating the same points in a circle
For your specific case please file bug reports
We (some KDE SIG people) are currently working on so called stability proposal [1]. That means one bigger update per release as KDE schedules are not in sync with Fedora releases. So this means - Fn release of Fedora is getting updates and users will get fresh software (rawhide is not an option), Fn-1 is considered as stable, without any "mayor" updates but it's still quite fresh so users don't have (are not forced) to switch to brand new release, probably breaking more than just update.
One of reasons we can be now much more conservative is that KDE is now in very good shape and few releases ago we couldn't let users with for example 4.0, 4.1 releases. Now it's not so important to do big steps as changes are not so visible
FKDESCo is going to vote probably on next meeting, Tuesday 09 14:00 UTC. So please, Fedora KDE users - comment these changes! We're working for you! CC'ing kde@lists.fpo.
[1] https://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
Jaroslav
Rahul
Jaroslav Reznik wrote:
So please, Fedora KDE users - comment these changes!
I prefer to get the releases as KDE releases them, instead of having to wait... and wait... and wait...
I scanned the Stability Proposal document that had been linked. Here is what I think:
As I had expected, breaking up the monolithic packages into individual packages is a whole lot of unnecessary work. Better to provide releases as they occur, than to waste time unnecessarily breaking down the monolithic packages. To what end and benefit? Who, nowadays, doesn't have at least one hard drive of at least 80-100GB, likely more (I have 3 drives, 2x300GB and1x200GB, the latter an old pata that will eventually get phased out, and I actually use only about 80GB for my own archives! That's a lot of space to spare).
I think it is unnecessary to provide the latest releases for any releases except the current and rawhide. If people don't bother to upgrade to the current release, then they obviously don't care to run a cutting edge system, so there is no point in providing it at the expense of a whole lot of work. It only takes an evening to download a live cd, install it, and do some rudimentary configurations. The rest can be achieved as one actually uses the system, so there is no excuse for not running the latest release. Considering that a lot of the work is done by volunteers (or are you, all you redhat/fedora people?), this is a fabulous system all for free and not even money can purchase anything better.
Yes, it is true that KDE 4 has matured immensely and it truly is difficult to notice all of the improvements and bug fixes. Nevertheless, I personally do enjoy finding the occasional irritating quirk disappear after a yum update.
Definitely, old releases should receive only the necessary bug fixes, not new features. This is a terrible waste of manpower.
Fedora advertises and distinguishes itself from other distros by being cutting edge. This is what I expect (although I would not likely jump ship, were the aforementioned changes implemented), as there is no other distro offering cutting edge and stability and quality, as fedora does.
To save man-hours, it might be better to scrap kde-redhat and just stick to updates and updates- testing. I would enable updates-testing (and sometimes I even pull something off koji manually), but many would stick to the safer route of just enabling updates.
It is a waste of time for a cutting edge distro to support old versions.
I can say, that aside from a very rare scare for a night, I have had no reason not to be ecstatic about this distro and the benefits of running it. No other distro offers what fedora offers.
The musings of an avid fedora user.
Petrus de Calguarium wrote:
I think it is unnecessary to provide the latest releases for any releases except the current and rawhide. If people don't bother to upgrade to the current release, then they obviously don't care to run a cutting edge system, so there is no point in providing it at the expense of a whole lot of work. It only takes an evening to download a live cd, install it, and do some rudimentary configurations. The rest can be achieved as one actually uses the system, so there is no excuse for not running the latest release. Considering that a lot of the work is done by volunteers (or are you, all you redhat/fedora people?), this is a fabulous system all for free and not even money can purchase anything better.
[snip]
Definitely, old releases should receive only the necessary bug fixes, not new features. This is a terrible waste of manpower.
It's actually almost no extra work to build the updates also for the previous stable release. We have to build them for the current stable anyway. It just means doing the usual routine (copying the specfile, committing and running make tag and make build BUILD_FLAGS=--nowait) twice instead of once (and even the commit can be done for both at once by committing in the parent directory), which takes only a few seconds extra, the builds run in parallel. Doing the updates for only one Fedora release would not be a significant saving of time or effort. Actually actively fixing bugs in the old, no longer supported by upstream branch would actually be MORE work.
To save man-hours, it might be better to scrap kde-redhat and just stick to updates and updates- testing. I would enable updates-testing (and sometimes I even pull something off koji manually), but many would stick to the safer route of just enabling updates.
kde-redhat is also very little work, usually just rebuilding stuff from Rawhide for the unstable repository, it's basically handled by 1 person (Rex Dieter) and it has been extremely helpful in helping to get prereleases tested and thus to prevent some disasters with the update to the actual release.
Kevin Kofler
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
It's actually almost no extra work to build the updates also for the previous stable release. We have to build them for the current stable anyway. It just means doing the usual routine (copying the specfile, committing and running make tag and make build BUILD_FLAGS=--nowait) twice instead of once (and even the commit can be done for both at once by committing in the parent directory), which takes only a few seconds extra, the builds run in parallel.
Builds are easy. Do you not do any testing?
Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
It's actually almost no extra work to build the updates also for the previous stable release. We have to build them for the current stable anyway. It just means doing the usual routine (copying the specfile, committing and running make tag and make build BUILD_FLAGS=--nowait) twice instead of once (and even the commit can be done for both at once by committing in the parent directory), which takes only a few seconds extra, the builds run in parallel.
Builds are easy. Do you not do any testing?
We do (actually, kde-redhat and updates-testing testers do most of it, but several KDE SIG packagers also run the testing stuff themselves), but most of it is on the latest stable release, it's not like the exact same KDE will be completely different on the previous stable release to the extent of requiring completely separate testing. There was one positive report (+1 karma, everything worked for the user) for F11 in Bodhi (and no reports of breakage), and IIRC there were other F11 users who reported it working on IRC, that's more than enough. AFAIK, none of the issues found are specific to F11.
Kevin Kofler
On Thu 4 March 2010 12:14:55 pm Petrus de Calguarium wrote:
Jaroslav Reznik wrote:
So please, Fedora KDE users - comment these changes!
I prefer to get the releases as KDE releases them, instead of having to wait... and wait... and wait...
I scanned the Stability Proposal document that had been linked. Here is what I think:
As I had expected, breaking up the monolithic packages into individual packages is a whole lot of unnecessary work. Better to provide releases as they occur, than to waste time unnecessarily breaking down the monolithic packages. To what end and benefit? Who, nowadays, doesn't have at least one hard drive of at least 80-100GB, likely more (I have 3 drives, 2x300GB and1x200GB, the latter an old pata that will eventually get phased out, and I actually use only about 80GB for my own archives! That's a lot of space to spare).
If we want to consider shipping a KDE Netbook spin for Fedora 14 (which has been thrown out as an idea by a few of us in the SIG as a good idea, and is indeed being discussed right now :) ) breaking the packages up would be a Good Thing as we could create a smaller, more targeted spin. (imo, others seem to disagree) Not everyone has a RealBigHarddrive, unfortunately.
I think it is unnecessary to provide the latest releases for any releases except the current and rawhide. If people don't bother to upgrade to the current release, then they obviously don't care to run a cutting edge system, so there is no point in providing it at the expense of a whole lot of work. It only takes an evening to download a live cd, install it, and do some rudimentary configurations. The rest can be achieved as one actually uses the system, so there is no excuse for not running the latest release. Considering that a lot of the work is done by volunteers (or are you, all you redhat/fedora people?), this is a fabulous system all for free and not even money can purchase anything better.
Yes, it is true that KDE 4 has matured immensely and it truly is difficult to notice all of the improvements and bug fixes. Nevertheless, I personally do enjoy finding the occasional irritating quirk disappear after a yum update.
Definitely, old releases should receive only the necessary bug fixes, not new features. This is a terrible waste of manpower.
The problem is that there _aren't_ bug fixes for these old releases. When 4.x comes out, upstream pretty much drops development on 4.x-1 except for security issues which are backported from 4.x. This leaves us in the tough position of "oh crap, there's $importantfix, in 4.x, but we either need to *spend the manpower* to backport it ourselves, or ship buggy/security-issue-plagued software. :( As it is, for most of Fn-1 updates, at least in the sig, to 4.x are simple and rarely need Fn-1 specific fixes.
Fedora advertises and distinguishes itself from other distros by being cutting edge. This is what I expect (although I would not likely jump ship, were the aforementioned changes implemented), as there is no other distro offering cutting edge and stability and quality, as fedora does.
To save man-hours, it might be better to scrap kde-redhat and just stick to updates and updates- testing. I would enable updates-testing (and sometimes I even pull something off koji manually), but many would stick to the safer route of just enabling updates.
Again, this would actually take _more_ manpower in the end, if we had QA do the testing instead of kde-redhat users. kde-redhat basically ships rawhide built for Fn, which is a Good Thing, because it gives the upcoming updates/updates-testing release a bunch more testing than sticking it only in rawhide would deliver. There's little manpower involved in Rex taking rawhide's spec file and sources, throwing them in kde-redhat's mock and letting it run (by all means, correct me if I'm wrong, Rex!) and the testing is invaluable.
It is a waste of time for a cutting edge distro to support old versions.
I can say, that aside from a very rare scare for a night, I have had no reason not to be ecstatic about this distro and the benefits of running it. No other distro offers what fedora offers.
The musings of an avid fedora user.
The ramblings of an avid fedora user :) Ryan
On Thu, 2010-03-04 at 13:59 -0700, Ryan Rix wrote:
The problem is that there _aren't_ bug fixes for these old releases. When 4.x comes out, upstream pretty much drops development on 4.x-1 except for security issues which are backported from 4.x. This leaves us in the tough position of "oh crap, there's $importantfix, in 4.x, but we either need to *spend the manpower* to backport it ourselves, or ship buggy/security-issue-plagued software. :(
You just said that upstream backports security issues, so your sticking with 4.x-1, you'd have security fixes for it.
On Thursday 04 March 2010 22:13:05 Jesse Keating wrote:
On Thu, 2010-03-04 at 13:59 -0700, Ryan Rix wrote:
The problem is that there _aren't_ bug fixes for these old releases. When 4.x comes out, upstream pretty much drops development on 4.x-1 except for security issues which are backported from 4.x. This leaves us in the tough position of "oh crap, there's $importantfix, in 4.x, but we either need to *spend the manpower* to backport it ourselves, or ship buggy/security-issue-plagued software. :(
You just said that upstream backports security issues, so your sticking with 4.x-1, you'd have security fixes for it.
Lot of security fixes (especially KHTML ones) are coming from us ;-) Thanks to security team guys for great work spotting security issues!!!
Problem is with bugfixes - usually it's not easy to backport stuff as KDE upstream is not just patching but lot of fixes are whole design fixes.
Jaroslav
On 03/04/2010 10:59 PM, Ryan Rix wrote:
The problem is that there _aren't_ bug fixes for these old releases. When 4.x comes out, upstream pretty much drops development on 4.x-1 except for security issues which are backported from 4.x.
If upstream really issues security fixes for 4.x-1, then this is pretty much perfect. We get 4 or 5 bug fix releases, and after that only security fixes. One would imagine that with 4 or 5 bug fix releases that branch has become stable enough to not need massive patch backporting.
Kalev Lember wrote:
If upstream really issues security fixes for 4.x-1,
Their security advisories include patches, which usually either apply just fine to the old releases or have a version for the old releases included.
then this is pretty much perfect. We get 4 or 5 bug fix releases, and after that only security fixes. One would imagine that with 4 or 5 bug fix releases that branch has become stable enough to not need massive patch backporting.
But this is really just imagination. 4.4.0 fixes hundreds if not thousands of bugs compared to 4.3.5 (upstream claims 7293 bugs and 1433 RFEs have been fixed in 4.4.0, but that is some automated Bugzilla query which probably doesn't understand the exact release the bug was fixed in, so this may be compared to 4.3.0 rather than 4.3.5). Such a large piece of software will always have bugs. "If it ain't broke, don't fix it" doesn't really work on that kind of software.
Kevin Kofler
Petrus de Calguarium wrote:
As I had expected, breaking up the monolithic packages into individual packages is a whole lot of unnecessary work. Better to provide releases as they occur, than to waste time unnecessarily breaking down the monolithic packages. To what end and benefit? Who, nowadays, doesn't have at least one hard drive of at least 80-100GB, likely
You have heard of netbooks, yes? SSD's? I have all of 4 GiB, and not all of that available for packages.
IIRC I had to remove kcalc because I can't afford to install the entire printing stack.
On Friday 05 March 2010 18:37:06 Matthew Woehlke wrote:
Petrus de Calguarium wrote:
As I had expected, breaking up the monolithic packages into individual packages is a whole lot of unnecessary work. Better to provide releases as they occur, than to waste time unnecessarily breaking down the monolithic packages. To what end and benefit? Who, nowadays, doesn't have at least one hard drive of at least 80-100GB, likely
You have heard of netbooks, yes? SSD's? I have all of 4 GiB, and not all of that available for packages.
We are planning some splits because we're planning KDE netbook spin. Netbook Plasma is new and very interesting piece of software and of course we'd like to support even old EEE 701 - I have one next to me ;-) Hopefully it's going to be F14 stuff.
Jaroslav
IIRC I had to remove kcalc because I can't afford to install the entire printing stack.
On Mon, Mar 8, 2010 at 11:01 AM, Jaroslav Reznik jreznik@redhat.com wrote:
On Friday 05 March 2010 18:37:06 Matthew Woehlke wrote:
Petrus de Calguarium wrote:
As I had expected, breaking up the monolithic packages into individual packages is a whole lot of unnecessary work. Better to provide releases as they occur, than to waste time unnecessarily breaking down the monolithic packages. To what end and benefit? Who, nowadays, doesn't have at least one hard drive of at least 80-100GB, likely
You have heard of netbooks, yes? SSD's? I have all of 4 GiB, and not all of that available for packages.
We are planning some splits because we're planning KDE netbook spin. Netbook Plasma is new and very interesting piece of software and of course we'd like to support even old EEE 701 - I have one next to me ;-) Hopefully it's going to be F14 stuff.
Jaroslav
I read on few websites that Fedora 13 should have KDE Netbook Plasma but I can't see any package in current Fedora 13 repositories. How do I turn on KDE Netbook Plasma for Fedora 13?
Cheers!
On Sat 15 May 2010 1:16:26 pm Valent Turkovic wrote:
On Mon, Mar 8, 2010 at 11:01 AM, Jaroslav Reznik jreznik@redhat.com
wrote:
On Friday 05 March 2010 18:37:06 Matthew Woehlke wrote:
Petrus de Calguarium wrote:
As I had expected, breaking up the monolithic packages into individual packages is a whole lot of unnecessary work. Better to provide releases as they occur, than to waste time unnecessarily breaking down the monolithic packages. To what end and benefit? Who, nowadays, doesn't have at least one hard drive of at least 80-100GB, likely
You have heard of netbooks, yes? SSD's? I have all of 4 GiB, and not
all
of that available for packages.
We are planning some splits because we're planning KDE netbook spin. Netbook Plasma is new and very interesting piece of software and of course we'd like to support even old EEE 701 - I have one next to me
;-)
Hopefully it's going to be F14 stuff.
Jaroslav
I read on few websites that Fedora 13 should have KDE Netbook Plasma but I can't see any package in current Fedora 13 repositories. How do I turn on KDE Netbook Plasma for Fedora 13?
Cheers!
The same way you do it for any distro... System Settings->Appearance-
Workspace, set Workspace Type to Netbook. There aren't any packages to
install outside of the default kde packages (kdebase-workspace for the minimum, or @kde-desktop for the full kde packageset.)
Note that for Fedora 14, we're targeting the creation of a KDE netbook spin which will automate all of this...
But this isn't really related to the Development of Fedora at all...
Ryan
Thank you for your reply. I'm looking forward to Netbook Respin.
Everybody writes how great KDE Netbook Plasma and doing reviews but not in single one nobody mentioned how to turn it on :(
Is it possible to have this choice during login GDM/KDM screen? So that some users can login into regular KDE and some into Netbook version?
The same way you do it for any distro... System Settings->Appearance-
Workspace, set Workspace Type to Netbook. There aren't any packages to
install outside of the default kde packages (kdebase-workspace for the minimum, or @kde-desktop for the full kde packageset.)
Note that for Fedora 14, we're targeting the creation of a KDE netbook spin which will automate all of this...
But this isn't really related to the Development of Fedora at all...
Ryan
-- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ ==
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 05/16/2010 01:28 PM, Valent Turkovic wrote:
Thank you for your reply. I'm looking forward to Netbook Respin.
Everybody writes how great KDE Netbook Plasma and doing reviews but not in single one nobody mentioned how to turn it on :(
Is it possible to have this choice during login GDM/KDM screen? So that some users can login into regular KDE and some into Netbook version?
You are again posting your questions to multiple lists. Please stick to one. In this case, Fedora KDE or users list would be the appropriate forum.
Rahul
Rahul Sundaram wrote:
Whether it would be a separate backports repo or merely some more conservativeness in our update stream
FWIW, for stuff like KDE, if we don't allow new feature upgrades even in the current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
I would argue having this within Fedora infrastructure would be better as it would prevent proliferation of third-party repos replacing Fedora packages and the resulting compatibility issues (see e.g. the chaos we're having for RHEL with third-party repositories replacing official packages with newer versions and the resulting dependency hell) and as it would also provide a place for new versions of less commonly-used applications.
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
But I think having yet another thread about update policies will be frowned upon by the moderators. Instead, let's please think about repairing this breakage now that it happened, i.e. get bug reports filed etc.
Kevin Kofler
On 03/04/2010 07:27 PM, Kevin Kofler wrote:
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
The whole point is that you will invariably find such breakage when pushing updates like this *after* the release and this is precisely why there are huge discussions on this topic and sooner you realize that no matter how careful you are you only increase the risks by doing such updates mid-release the better off we are towards a reasonable level of compromise
Rahul
On 03/04/2010 07:18 AM, Rahul Sundaram wrote:
On 03/04/2010 07:27 PM, Kevin Kofler wrote:
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
The whole point is that you will invariably find such breakage when pushing updates like this *after* the release and this is precisely why there are huge discussions on this topic and sooner you realize that no matter how careful you are you only increase the risks by doing such updates mid-release the better off we are towards a reasonable level of compromise
Rahul
Kevin/KDE SIG -
I would also like you to consider that simply changing the behavior of a system, while not technically a bug or regression, can be frustrating to a lot of users (I have reports of different looking panels, different task bar graphics behavior). Especially to sysadmins like myself who manage multiple users' systems and have to deal with and explain to the users all of the changes that happen. It is much easier for me to say - when is a good time to upgrade to Fn? and the user can prepare for changes and time it to not coincide with other deadlines, etc.
And please, just assume like Rahul says that there *will* be bugs/regressions that aren't found in testing for major updates like this, and take that into consideration.
I'm sure some (most?) of my frustration needs to be directed with KDE upstream and their cavalier attitude towards preserving settings and data during updates, but I also really don't want to have to deal with this any more than I have to.
(Off to track down changes in XRANDR behavior with 4.4.0 ....)
On Thursday 04 March 2010 17:33:20 Orion Poplawski wrote:
On 03/04/2010 07:18 AM, Rahul Sundaram wrote:
On 03/04/2010 07:27 PM, Kevin Kofler wrote:
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
The whole point is that you will invariably find such breakage when pushing updates like this *after* the release and this is precisely why there are huge discussions on this topic and sooner you realize that no matter how careful you are you only increase the risks by doing such updates mid-release the better off we are towards a reasonable level of compromise
Rahul
Kevin/KDE SIG -
I would also like you to consider that simply changing the behavior of a system, while not technically a bug or regression, can be frustrating to a lot of users (I have reports of different looking panels, different task bar graphics behavior). Especially to sysadmins like myself who manage multiple users' systems and have to deal with and explain to the users all of the changes that happen. It is much easier for me to say - when is a good time to upgrade to Fn? and the user can prepare for changes and time it to not coincide with other deadlines, etc.
And please, just assume like Rahul says that there *will* be bugs/regressions that aren't found in testing for major updates like this, and take that into consideration.
I'm sure some (most?) of my frustration needs to be directed with KDE upstream and their cavalier attitude towards preserving settings and data during updates, but I also really don't want to have to deal with this any more than I have to.
That's the problem - it's just postponed to upgrade from update - you can choose one hell from 1. break update, 2. break upgrade. None of this should happen.
(Off to track down changes in XRANDR behavior with 4.4.0 ....)
On 03/04/2010 10:08 PM, Jaroslav Reznik wrote:
That's the problem - it's just postponed to upgrade from update - you can choose one hell from 1. break update, 2. break upgrade. None of this should happen.
It has already happened and it will happen again and again and no amount of idealistic wishes is going to change that and by postponing disruptive changes to a new release time you make things more manageable for users
Rahul
On 3/4/2010 9:38 AM, Jaroslav Reznik wrote:
That's the problem - it's just postponed to upgrade from update - you can choose one hell from 1. break update, 2. break upgrade. None of this should happen.
To reiterate - I would *much* prefer change around and upgrade than an update. It's the mind set you are in when you do one versus the other that makes all the difference (for me).
Orion Poplawski
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
I would argue having this within Fedora infrastructure would be better as it would prevent proliferation of third-party repos replacing Fedora packages and the resulting compatibility issues (see e.g. the chaos we're having for RHEL with third-party repositories replacing official packages with newer versions and the resulting dependency hell) and as it would also provide a place for new versions of less commonly-used applications.
So the thing is that KDE SIG wants to prevent any other activity and keep the strings in own hands. That's why nobody can't enjoy the upstream's intended stability in bugfix releases and plan major upgrades.
If someone wants to fork, whatever, let them do it. That's why Fedora moves to the git, to make it easier.
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
What you've just proved could have been enough for some companies trying to run Fedora on their employees desktops and they probably think that they've seen enough. TCO is rising too high when you cannot do sane stable release updates.
In other words, SIG's current policy is doing more harm than good for Fedora.
But I think having yet another thread about update policies will be frowned upon by the moderators. Instead, let's please think about repairing this breakage now that it happened, i.e. get bug reports filed etc.
Yes, let's fix the bug instead the policy that caused it in the first place, sigh.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
On Thu, Mar 4, 2010 at 3:30 PM, Juha Tuomala Juha.Tuomala@iki.fi wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
There's no need to continued attack the KDE SIG. You're not a first time linuxer. If you're that scared as you said in your OP, then you should use yum to exclude that stuff. If you dont know how: man yum ; man yum.conf
But of course, you couldn't then bash others.
On Thu, 4 Mar 2010, Thomas Janssen wrote:
On Thu, Mar 4, 2010 at 3:30 PM, Juha Tuomala Juha.Tuomala@iki.fi wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
There's no need to continued attack the KDE SIG. You're not a first time linuxer. If you're that scared as you said in your OP, then you should use yum to exclude that stuff. If you dont know how: man yum ; man yum.conf
But of course, you couldn't then bash others.
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
-Mike
On Thu, Mar 4, 2010 at 3:45 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Thu, 4 Mar 2010, Thomas Janssen wrote:
On Thu, Mar 4, 2010 at 3:30 PM, Juha Tuomala Juha.Tuomala@iki.fi wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
There's no need to continued attack the KDE SIG. You're not a first time linuxer. If you're that scared as you said in your OP, then you should use yum to exclude that stuff. If you dont know how: man yum ; man yum.conf
But of course, you couldn't then bash others.
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
You're absolutely right here. And it gets discussed heavily. I just get slowly sick of all that bashing around. Doesn't matter which way. The KDE SIG needs a bit time to discuss and decide what exactly will be done (for sure the right thing to prevent that kind of breakage). Though systematic annoying pestering will not help at all.
I think the point is already very clear and work (thoughts, discussion) on it is in progress.
Maybe i should send a mail and ask if it's possible to stop attacking others. I start to get agressive myself, and i dont like that.
Mike McGrath wrote:
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
To be clear, no one is ignoring anything. (What a silly thing to say?... well, maybe not so silly... means there's a bad pr/perception problem. :( )
Like most any group making hard decisions, the KDE SIG bases them on the best information available. Fact is, we extensively tested this new version for over a month, and every serious issue/blocker that was reported or identified was addressed prior to releasing this.
Unfortunately, it seems there were more problems than what we were aware of when the decision was made to do the 4.4.0 (stable) update. Yeah, that sucks.
So here we are in a bit of a pickle, with many unhappy folks. Brain dump on "how to make things better(tm)" (or for you glass half-empty folks, "how to make things suck less(tm)"):
1. Improve communication. Seems there's a bit of disconnected between kde sig plans/intentions and the expectations of some significant portion of other fedora contributors and user-base. Also, continue to work toward making constructive feedback the obvious and expected norm. Clearly define what this is, and it's intrinsic high value. imo, folks like to know that they are being heard, and to feel that their constructive participation yields positive results.
(dunno about everyone else, but this, to me, seems to be the biggest "problem" at hand)
2. better and more testing. Work more to tap into ongoing fedora qa/testing efforts.
3. adjust plans/policy wrt kde upgrades. a. implement kde stability proposal as is (to limit 4.x type upgrades to at most one per fedora release)
b. simply do new 4.x versions only for fn+1? pros: less chance to disrupt current installations. cons: pushes off the problems to users upgrading to fn+1.
c. defer any sig decisions, wait for fedora-wide fesco policy/guideline
....
99. profit.
-- Rex
On Thu, 4 Mar 2010, Rex Dieter wrote:
Mike McGrath wrote:
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
To be clear, no one is ignoring anything. (What a silly thing to say?... well, maybe not so silly... means there's a bad pr/perception problem. :( )
Well, so far all I've heard is that pushing the update was the right thing to do. In fact, it was so the right thing to do that I have yet to see acknolwedgement that had any downsides at all, thus why I used the term "ignore".
Like most any group making hard decisions, the KDE SIG bases them on the best information available. Fact is, we extensively tested this new version for over a month, and every serious issue/blocker that was reported or identified was addressed prior to releasing this.
Unfortunately, it seems there were more problems than what we were aware of when the decision was made to do the 4.4.0 (stable) update. Yeah, that sucks.
So here's a question. I'm just going to throw it out there. Since, as with this update, it's impossible to know all of the problems that will come up when pushing a release out, why not just wait 2 months so everyone does it when they upgrade to F13? That way, I have a reason to upgrade to F13, and F12 doesn't get a reputation for breaking stuff in the middle of a work week?
None of us know what we don't know, that's why some of us like to be conservative. Especially since KDE is currently the main thing I use that puts bread on my table at night. I know that's dramatic, but I was late to a meeting Tuesday because daily updates that would normally have taken 20 minutes or less, took well over an hour because I had things to fix.
The KDE sig has said there's people that only use Fedora because it is kept super up to date. What is the KDE sig doing to get the actual metrics of what people that would prefer a stable release vs the bleeding edge?
- Improve communication. Seems there's a bit of disconnected between kde
sig plans/intentions and the expectations of some significant portion of other fedora contributors and user-base. Also, continue to work toward making constructive feedback the obvious and expected norm. Clearly define what this is, and it's intrinsic high value. imo, folks like to know that they are being heard, and to feel that their constructive participation yields positive results.
(dunno about everyone else, but this, to me, seems to be the biggest "problem" at hand)
By "Improve communication" I'd say do an actual study to see what your users want then publish those results. The communication side of things here needs y'all to listen as well not just talk at us.
- better and more testing. Work more to tap into ongoing fedora
qa/testing efforts.
- adjust plans/policy wrt kde upgrades.
a. implement kde stability proposal as is (to limit 4.x type upgrades to at most one per fedora release)
b. simply do new 4.x versions only for fn+1? pros: less chance to disrupt current installations. cons: pushes off the problems to users upgrading to fn+1.
c. defer any sig decisions, wait for fedora-wide fesco policy/guideline
I'm hoping for this as well, if we're supposed to be tracking upstream as closely as possible, I'll certainly do it though my preference would be for more stable releases. Not knowing is really eating away at me.
-Mike
On Thu, Mar 4, 2010 at 16:20, Rex Dieter rdieter@math.unl.edu wrote:
Mike McGrath wrote:
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
To be clear, no one is ignoring anything. (What a silly thing to say?... well, maybe not so silly... means there's a bad pr/perception problem. :( )
Like most any group making hard decisions, the KDE SIG bases them on the best information available. Fact is, we extensively tested this new version for over a month, and every serious issue/blocker that was reported or identified was addressed prior to releasing this.
Unfortunately, it seems there were more problems than what we were aware of when the decision was made to do the 4.4.0 (stable) update. Yeah, that sucks.
Yes there is the odd regression and i have been bitten by the odd one over time myself but in the vast majority of cases i have had no regressions at all by the time the updates hit stable. If i wanted an absolutely rock solid distribution and desktop there are plenty of other choices out there but i have personally found the improvements with each update to far out weigh the very occasional regressions and bugs (that mostly includes the betas and rcs from kde-redhat too). Keep up the great work.
So here we are in a bit of a pickle, with many unhappy folks. Brain dump on "how to make things better(tm)" (or for you glass half-empty folks, "how to make things suck less(tm)"):
- Improve communication. Seems there's a bit of disconnected between kde
sig plans/intentions and the expectations of some significant portion of other fedora contributors and user-base. Also, continue to work toward making constructive feedback the obvious and expected norm. Clearly define what this is, and it's intrinsic high value. imo, folks like to know that they are being heard, and to feel that their constructive participation yields positive results.
(dunno about everyone else, but this, to me, seems to be the biggest "problem" at hand)
A simple way to encourage constructive input from users on both the state of play and providing more bug reports might be to regularly (perhaps even daily as soon as a significant update comes along) to post a list of all the bugs that are reported against the updates (both blockers and not). That might encourage people to report bugs, give people an idea of what kind of problems to expect during testing, feedback from users about what they consider blockers and what not, give users an idea about how close things are to being released. All of this information would then be useful for during the meetings to decide if the updates really are ready in the eyes of the end users.
- better and more testing. Work more to tap into ongoing fedora
qa/testing efforts.
That can never hurt although i would say the testing provided by users of kde-redhat already provides more useful feedback than the qa team probably has the resources for.
- adjust plans/policy wrt kde upgrades.
a. implement kde stability proposal as is (to limit 4.x type upgrades to at most one per fedora release)
If you do one update like that per release than you may as well do the rest.
b. simply do new 4.x versions only for fn+1? pros: less chance to disrupt current installations. cons: pushes off the problems to users upgrading to fn+1.
I generally keep up to date with the latest release but i would say a better balance might be just to implement everything in the next release and kde-redhat as is currently done. Then in the latest release and just perhaps leave the updates for the most stable release in testing just a bit longer to make extra sure regressions are fixed as best as possible.
c. defer any sig decisions, wait for fedora-wide fesco policy/guideline
In my opinion most of fesco has lost it's mind even contemplating the recent suggestions. Please don't destroy one of Fedora's greatest strengths for the sake of some morons who want Fedora to be RedHat with a different colored hat... I am getting fed up of Fedora's latest identity crisis and if the KDE SIG just turns into a sheep then that would be the last straw for me.
....
- profit.
-- Rex
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 03/04/2010 11:28 PM, John5342 wrote:
In my opinion most of fesco has lost it's mind even contemplating the recent suggestions. Please don't destroy one of Fedora's greatest strengths for the sake of some morons who want Fedora to be RedHat with a different colored hat... I am getting fed up of Fedora's latest identity crisis and if the KDE SIG just turns into a sheep then that would be the last straw for me.
While it is alright to criticize positions it is not acceptable to engage in name calling and please refrain from doing so
Rahul
John5342 wrote:
A simple way to encourage constructive input from users on both the state of play and providing more bug reports might be to regularly (perhaps even daily as soon as a significant update comes along) to post a list of all the bugs that are reported against the updates (both blockers and not). That might encourage people to report bugs, give people an idea of what kind of problems to expect during testing, feedback from users about what they consider blockers and what not, give users an idea about how close things are to being released. All of this information would then be useful for during the meetings to decide if the updates really are ready in the eyes of the end users.
We're already doing that (for the big updates like 4.4; we found it not needed for the bugfix-only point releases), it's called a "tracker bug", see e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.4 https://bugzilla.redhat.com/showdependencytree.cgi?id=533921&hide_resolv...
In my opinion most of fesco has lost it's mind even contemplating the recent suggestions. Please don't destroy one of Fedora's greatest strengths for the sake of some morons who want Fedora to be RedHat with a different colored hat... I am getting fed up of Fedora's latest identity crisis and if the KDE SIG just turns into a sheep then that would be the last straw for me.
Let me be clear: while it is not my intention at all to be a "sheep" and while I'm strongly opposing that sort of policies, if FESCo were to mandate that all Fedora updates may only be to bugfix releases (or worse, that new upstream versions are not allowed in updates at all), KDE SIG would not be in a position to do something else (in the official Fedora updates; of course, kde-redhat is a different story and kde-redhat stable might carry the updates Fedora doesn't want anymore). Ignoring the policy would not be a workable solution, it could lead to the updates getting rejected or other sanctions and it'd also confuse users (e.g. "Why is 4.4.0 in the updates, the policy says such updates are not allowed?"). So the only thing we can do is to try to prevent such a policy from being passed in the first place.
Kevin Kofler
On Thu, Mar 4, 2010 at 19:00, Kevin Kofler kevin.kofler@chello.at wrote:
John5342 wrote:
A simple way to encourage constructive input from users on both the state of play and providing more bug reports might be to regularly (perhaps even daily as soon as a significant update comes along) to post a list of all the bugs that are reported against the updates (both blockers and not). That might encourage people to report bugs, give people an idea of what kind of problems to expect during testing, feedback from users about what they consider blockers and what not, give users an idea about how close things are to being released. All of this information would then be useful for during the meetings to decide if the updates really are ready in the eyes of the end users.
We're already doing that (for the big updates like 4.4; we found it not needed for the bugfix-only point releases), it's called a "tracker bug", see e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.4 https://bugzilla.redhat.com/showdependencytree.cgi?id=533921&hide_resolv...
I was referring primarily to making it more visible on the mailing lists. Being vocal to the users and testers may well create the same in return. Obviously the purely testers will be aware of the tracker bugs (me included). I don't think there is anything wrong with the current way. Making it more visible by highlighting the list of bugs to the KDE testers might however draw in a few extra people and improve the feeling of openness about the updates even more than already. It was merely an extension of the current ideas as Rex appeared to be requesting.
In my opinion most of fesco has lost it's mind even contemplating the recent suggestions. Please don't destroy one of Fedora's greatest strengths for the sake of some morons who want Fedora to be RedHat with a different colored hat... I am getting fed up of Fedora's latest identity crisis and if the KDE SIG just turns into a sheep then that would be the last straw for me.
Let me be clear: while it is not my intention at all to be a "sheep" and while I'm strongly opposing that sort of policies, if FESCo were to mandate that all Fedora updates may only be to bugfix releases (or worse, that new upstream versions are not allowed in updates at all), KDE SIG would not be in a position to do something else (in the official Fedora updates; of course, kde-redhat is a different story and kde-redhat stable might carry the updates Fedora doesn't want anymore). Ignoring the policy would not be a workable solution, it could lead to the updates getting rejected or other sanctions and it'd also confuse users (e.g. "Why is 4.4.0 in the updates, the policy says such updates are not allowed?"). So the only thing we can do is to try to prevent such a policy from being passed in the first place.
Sorry. That was perhaps rather strongly worded. I was not suggesting going against policies if they are mandated. My complaint about sheep was towards the option of defering. Not the act of following what is mandated if such policies are passed. Until such stuff is mandated (hopefully never) everything should be done the right way. Not what fesco currently seems to be considering.
What i said about leaving Fedora behind if such policies are passed though and my views towards those members on fesco who are even considering these policies do however very much stand and i hope that such policies are never passed. It would be a real shame for an otherwise brilliant distribution and a waste of some great KDE packagers who are currently doing an excellent job. My current views towards the suggested policies and the fesco members considering such policies do however probably belong in another thread.
Kevin Kofler
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
John5342 wrote:
Sorry. That was perhaps rather strongly worded. I was not suggesting going against policies if they are mandated. My complaint about sheep was towards the option of defering. Not the act of following what is mandated if such policies are passed. Until such stuff is mandated (hopefully never) everything should be done the right way. Not what fesco currently seems to be considering.
Deferring means continuing with our current policy (always push minor feature releases, just leave disruptive major releases like KDE 4 (or KDE 4 ports of applications with significant rewriting and some feature regressions) to new releases, like we did for KDE in Fedora 8 vs. 9, and for applications as well, except in cases like Konversation where the KDE 4 port came with no feature regressions and no significant UI changes) unless/until FESCo mandates anything else. That's quite the opposite of sheepishly following suggested conservative policies.
Kevin Kofler
On Thu, Mar 4, 2010 at 9:50 PM, Rex Dieter rdieter@math.unl.edu wrote: [...]
- adjust plans/policy wrt kde upgrades.
a. implement kde stability proposal as is (to limit 4.x type upgrades to at most one per fedora release)
b. simply do new 4.x versions only for fn+1? pros: less chance to disrupt current installations. cons: pushes off the problems to users upgrading to fn+1.
Does that mean if Fedora N is released with KDE 4.x, the users get 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the latest-and-greatest, bleeding edge policy of Fedora. And yes, a lot of users will be unhappy if they have to wait 6 months to see the next KDE SC release in Fedora, /me included.
On 03/05/2010 10:16 AM, Rajeesh K Nambiar wrote:
Does that mean if Fedora N is released with KDE 4.x, the users get 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the latest-and-greatest, bleeding edge policy of Fedora.
If you would point me to such a "bleeding edge" policy then I could agree but I believe this is merely assumed by some and if you want the latest always you could use kde-redhat repo
Rahul
On Fri, Mar 05, 2010 at 01:15:50PM +0530, Rahul Sundaram wrote:
latest-and-greatest, bleeding edge policy of Fedora.
If you would point me to such a "bleeding edge" policy then I could agree but I believe this is merely assumed by some and if you want the latest always you could use kde-redhat repo
Maybe it isn't written down as a policy but in my mind it's a big part of the four foundations. Unless we want to make them "freedom friends frozen frustration" in the future ...
When I 'sell' Fedora at FLOSS events my main two arguments are:
1) Fedora gets you current software - not only is it often first in shipping new stuff (among other projects, I use xorg as an example) in new releases it is also the only major distribution that ships updated versions for a release.
2) It's easy to start contributing. Becoming a package maintainer takes a lot less time than for Debian / Ubuntu and rpm packaging is easier to grasp than building debs.
If we continue stacking additional constraints on the packager / update process and switch to a 'security and data-loss bugfixes only' policy for releases then I would loose both arguments and fedora would just be chasing ubuntu. I'd hate to see that happen as I'm pretty sure that the answer to who is the better ubuntu will always be ubuntu.
That said I'm pretty excited about the prospect of having AutoQA automatically test and reject updates and making the karma process easier for the user so that it can be promoted and relied upon in the future.
On 03/05/2010 02:06 PM, Sven Lankes wrote:
Maybe it isn't written down as a policy but in my mind it's a big part of the four foundations. Unless we want to make them "freedom friends frozen frustration" in the future ...
http://fedoraproject.org/wiki/Foundations
The four foundations have really nothing to do with a claim that we need to push new upstream versions as updates and yes while we are the first to ship a lot of new features that should be primarily limited to the time of the release and other distributions have given the choice by providing a backports repository to satisfy the people who want the bleeding edge stuff as updates
We have a written down policy that specifically recommends that our maintainers consider the issue of regressions seriously and not push every upstream release into the updates repository
http://fedoraproject.org/wiki/Package_update_guidelines
It might be different for leaf or niche packages but kde is a very big update and the risk of regressions has always been high
Rahul
Rahul Sundaram wrote:
We have a written down policy that specifically recommends that our maintainers consider the issue of regressions seriously and not push every upstream release into the updates repository
1. That policy is not mandatory, just indicative: "These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement." 2. That policy doesn't say that no new versions or even no feature upates should be pushed. Quite the opposite, it says "A simple rule of thumb might be to not push the new release unless it fixes a problem that a user has reported or introduces a new feature that Fedora users have previously requested." The KDE feature updates were definitely requested by our users and they also fixed some bugs (actual BUGS, not RFEs) reported in Fedora, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=539395 https://bugzilla.redhat.com/show_bug.cgi?id=557530 https://bugzilla.redhat.com/show_bug.cgi?id=565415 (not to mention the many upstream bugs, some of which actually happen to have been filed by Fedora users, also fixed). 3. Yes, regressions should be considered, but that's what updates-testing is for, as is also spelled out in that policy.
So I don't see that policy as backing your claims at all.
Kevin Kofler
On 03/05/2010 03:45 PM, Kevin Kofler wrote:
So I don't see that policy as backing your claims at all.
Of course you don't which is part of the problem since you continue to not treat the risk of regressions as seriously as you should even though the latest push did cause problems despite careful planning and testing and since the current guidelines do not attempt to cover every possible scenario there is enough room for you to overlook the most important part of the policy which is "maintain stability" and if we break the desktop environment in an update we have clearly failed to do so
Rahul
On Fri, 2010-03-05 at 11:15 +0100, Kevin Kofler wrote:
Rahul Sundaram wrote:
We have a written down policy that specifically recommends that our maintainers consider the issue of regressions seriously and not push every upstream release into the updates repository
- That policy is not mandatory, just indicative:
"These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement." 2. That policy doesn't say that no new versions or even no feature upates should be pushed. Quite the opposite
So I don't see that policy as backing your claims at all.
That's because you're misreading Rahul's claims. Rahul was replying to a post which claimed Fedora has a 'policy' of being 'bleeding edge'. Rahul's point is that we don't, and the only policy we do have - even though, as he specifically notes, it's a weak one (he says 'specifically recommends', not 'requires') - is rather the opposite. If you'd left in the context from the post Rahul was replying to, this would have been clear.
2010/3/5 Adam Williamson awilliam@redhat.com:
On Fri, 2010-03-05 at 11:15 +0100, Kevin Kofler wrote:
Rahul Sundaram wrote:
We have a written down policy that specifically recommends that our maintainers consider the issue of regressions seriously and not push every upstream release into the updates repository
- That policy is not mandatory, just indicative:
"These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement." 2. That policy doesn't say that no new versions or even no feature upates should be pushed. Quite the opposite
So I don't see that policy as backing your claims at all.
That's because you're misreading Rahul's claims. Rahul was replying to a post which claimed Fedora has a 'policy' of being 'bleeding edge'. Rahul's point is that we don't, and the only policy we do have - even though, as he specifically notes, it's a weak one (he says 'specifically recommends', not 'requires') - is rather the opposite. If you'd left in the context from the post Rahul was replying to, this would have been clear.
Although when it was approved by fesco, it was discussed under the term "Update description guidelines", and from the short discussion archived on http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html it is not at all clear that the main intention was to discourage updates to stable releases. Instead the main focus was on the update descriptions.
- Thomas
On Fri, Mar 5, 2010 at 9:19 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2010-03-05 at 11:15 +0100, Kevin Kofler wrote:
Rahul Sundaram wrote:
We have a written down policy that specifically recommends that our maintainers consider the issue of regressions seriously and not push every upstream release into the updates repository
- That policy is not mandatory, just indicative:
"These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement." 2. That policy doesn't say that no new versions or even no feature upates should be pushed. Quite the opposite
So I don't see that policy as backing your claims at all.
That's because you're misreading Rahul's claims. Rahul was replying to a post which claimed Fedora has a 'policy' of being 'bleeding edge'.
Uh, oh - it wasn't a *claim*. Its just the popular saying, urban myth, a general feeling - you name it. It wasn't literal, just figurative, I hope you understand the essence.
Rahul's point is that we don't, and the only policy we do have - even though, as he specifically notes, it's a weak one (he says 'specifically recommends', not 'requires') - is rather the opposite. If you'd left in the context from the post Rahul was replying to, this would have been clear. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 2010-03-05 at 21:47 +0530, Rajeesh K Nambiar wrote:
That's because you're misreading Rahul's claims. Rahul was replying to a post which claimed Fedora has a 'policy' of being 'bleeding edge'.
Uh, oh - it wasn't a *claim*. Its just the popular saying, urban myth, a general feeling - you name it. It wasn't literal, just figurative, I hope you understand the essence.
Uh, what? How does what you said relate to what I said in any way?
Rahul wasn't claiming that Fedora has a strict conservative update policy. He was pointing out that Fedora does *not* have a strict bleeding-edge policy. Wherein is that 'urban myth', 'popular saying', 'a general feeling', or 'figurative'?
On 03/05/2010 09:53 PM, Adam Williamson wrote:
Uh, what? How does what you said relate to what I said in any way?
Rahul wasn't claiming that Fedora has a strict conservative update policy. He was pointing out that Fedora does *not* have a strict bleeding-edge policy. Wherein is that 'urban myth', 'popular saying', 'a general feeling', or 'figurative'?
I believe Rajeesh is saying that his reference to a policy was not literal but I have seen repeated claims that there is somehow a policy written or otherwise that Fedora is supposed to be bleeding edge where base components needs updates immediately and our written policy albeit a deliberately weak one does not support that assertion
Rahul
On Fri, Mar 5, 2010 at 9:53 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2010-03-05 at 21:47 +0530, Rajeesh K Nambiar wrote:
That's because you're misreading Rahul's claims. Rahul was replying to a post which claimed Fedora has a 'policy' of being 'bleeding edge'.
Uh, oh - it wasn't a *claim*. Its just the popular saying, urban myth, a general feeling - you name it. It wasn't literal, just figurative, I hope you understand the essence.
Uh, what? How does what you said relate to what I said in any way?
Sorry for causing confusion - Rahul made that statement in reply to my comment. That's how it was related.
Rahul wasn't claiming that Fedora has a strict conservative update policy. He was pointing out that Fedora does *not* have a strict bleeding-edge policy. Wherein is that 'urban myth', 'popular saying', 'a general feeling', or 'figurative'? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Mar 5, 2010 at 9:57 AM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 02:06 PM, Sven Lankes wrote:
Maybe it isn't written down as a policy but in my mind it's a big part of the four foundations. Unless we want to make them "freedom friends frozen frustration" in the future ...
http://fedoraproject.org/wiki/Foundations
The four foundations have really nothing to do with a claim that we need to push new upstream versions as updates and yes while we are the first to ship a lot of new features that should be primarily limited to the time of the release and other distributions have given the choice by providing a backports repository to satisfy the people who want the bleeding edge stuff as updates
We have a written down policy that specifically recommends that our maintainers consider the issue of regressions seriously and not push every upstream release into the updates repository
http://fedoraproject.org/wiki/Package_update_guidelines
It might be different for leaf or niche packages but kde is a very big update and the risk of regressions has always been high
I read about regressions all the time in KDE releases, over and over again. What's a regression you Rahul have faced and can you provide a BZ as well?
I read about regressions as it would have been thousands every release (yes, that's exactly as it sonds). We DO test our stuff as mentioned as well over and over again. AND we grow slowly under the roof of Fedora. Part of that growing IS that we give our users what they want. I myself have/had only ONE single regression with the update to 4.4.0. And that's even a regression only a handful of users face, cross distro.
The nepomuk problem some face is something that falls under, damn, that shouldn't happen, but sh!t happens. I saw a lot more and even terrible stuff happen in Fedora.
I can see the need and agree that maybe not every big push needs to go to N-1 releases. But not pushing 4.x.x relases to the currently "stable" N release is just plain wrong. That kills what Fedora stands for out there in the wild. To be a leading edge distribution. And dont come up again with rawhide. That's just ridiculous, because then i can run EVERY distro out there and use their rawhide/factory/cooker or whatever name they have. Leading edge doesn't stand only for "new technics adopted first".
Another thing, since you throw that links about package_update_guidelines around, some maintainers should also check what software is my software built against and dont push broken software without testing to stable because of that "mistake" ;)
Just to remind anyone, if you forgot, or dont know what Fedora stands for IN REAL LIFE, you might go out and check it. It stands exactly for what you terribly fight against. And people love it exactly for that. But sure, there's always the possibility to bend over and try as hard as you can to make something without an own identity.....
And no, not a single sentence is written aggressively. More with a big *sigh*
On 03/05/2010 03:55 PM, Thomas Janssen wrote:
I read about regressions all the time in KDE releases, over and over again. What's a regression you Rahul have faced and can you provide a BZ as well?
A while back a kde update caused kmail to stop working on imap accounts and I dont use the DE in Fedora anymore because I wanted to avoid such problems with big updates and while I don't have the bz number for that problem handy it would easy enough to find if you are interested and every big push has repeatedly brought out similar problems
Another thing, since you throw that links about package_update_guidelines around, some maintainers should also check what software is my software built against and dont push broken software without testing to stable because of that "mistake" ;)
This is seriously petty and I would point out that messing around with the buildroot as part of the big kde update is what caused the problem in the first place and yes I was told that future announcement would add more clarity and the sig would avoid buildroot overrides for future updates
Just to remind anyone, if you forgot, or dont know what Fedora stands for IN REAL LIFE, you might go out and check it. It stands exactly for what you terribly fight against.
You seem to assume that other people dont talk to Fedora users and that is wrong and I still differ from your position
Rahul
On Fri, Mar 5, 2010 at 11:41 AM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 03:55 PM, Thomas Janssen wrote:
I read about regressions all the time in KDE releases, over and over again. What's a regression you Rahul have faced and can you provide a BZ as well?
A while back a kde update caused kmail to stop working on imap accounts and I dont use the DE in Fedora anymore because I wanted to avoid such problems with big updates and while I don't have the bz number for that problem handy it would easy enough to find if you are interested and every big push has repeatedly brought out similar problems
So you filed a bug. I will search for it. So you stop'd using it, BUT you faced more problems like that. Now that's interesting. Or is it that you blow into the same horn as others do? If so, i would have expected more from you.
Another thing, since you throw that links about package_update_guidelines around, some maintainers should also check what software is my software built against and dont push broken software without testing to stable because of that "mistake" ;)
This is seriously petty and I would point out that messing around with the buildroot as part of the big kde update is what caused the problem in the first place and yes I was told that future announcement would add more clarity and the sig would avoid buildroot overrides for future updates
Indeed better announcements will save (almost) that problems. And a better system than buildroot overrides we're asking/asked for will help there as well. Though there's that link YOU provided and pointed fingers at US.
Just to remind anyone, if you forgot, or dont know what Fedora stands for IN REAL LIFE, you might go out and check it. It stands exactly for what you terribly fight against.
You seem to assume that other people dont talk to Fedora users and that is wrong and I still differ from your position
No, i just tell you (not only you, but all people) that they shouldn't forget about what Fedora stands for and the things we earn our love for. So the one who assumes something seems to be you. I don't want to convert you, so please keep your different position. But stay with what YOU know from experience and provide BZs for that mass of regressions/problems you faced. That's something YOU want from users as well who have a different position than you.
Thank you.
On 03/05/2010 04:33 PM, Thomas Janssen wrote:
So you filed a bug. I will search for it. So you stop'd using it, BUT you faced more problems like that. Now that's interesting. Or is it that you blow into the same horn as others do? If so, i would have expected more from you
I faced more problems in other places besides kde obviously and if you want another example there was a thunderbird update sometime before that caused issues with the indexing being turned in an update and setting aside personal experiences there has been ample proof of regressions in Fedora updates
better system than buildroot overrides we're asking/asked for will help there as well. Though there's that link YOU provided and pointed fingers at US.
I would ask you to drop this "you vs us" mentality and work on solving the issues that updates cause and consider how can we solve them
No, i just tell you (not only you, but all people) that they shouldn't forget about what Fedora stands for
The whole point is that Fedora stands for different things to different people and we need to find a good balance
Rahul
On Fri, Mar 5, 2010 at 12:12 PM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 04:33 PM, Thomas Janssen wrote:
So you filed a bug. I will search for it. So you stop'd using it, BUT you faced more problems like that. Now that's interesting. Or is it that you blow into the same horn as others do? If so, i would have expected more from you
I faced more problems in other places besides kde obviously and if you want another example there was a thunderbird update sometime before that caused issues with the indexing being turned in an update and setting aside personal experiences there has been ample proof of regressions in Fedora updates
Indeed. And i saw even worse regressions.
better system than buildroot overrides we're asking/asked for will help there as well. Though there's that link YOU provided and pointed fingers at US.
I would ask you to drop this "you vs us" mentality and work on solving the issues that updates cause and consider how can we solve them
Thank you, now we're speaking the same language. Yes, the KDE SIG wants the problems solved as well. It's just that repeated we are the bad guys that makes me sick slowly. I think we found (in that BIG threads) a handful very good options to fit everyones needs. Now it's time to wait for the Board to give FESCo their vision and see what FESCo wants to do with it. IMO.
Meanwhile we could stop to attack eatch other and try to relax a bit :) I hope FESCo will do the right thing to find a way that fits all of our users. The possibilitys are there.
No, i just tell you (not only you, but all people) that they shouldn't forget about what Fedora stands for
The whole point is that Fedora stands for different things to different people and we need to find a good balance
Right. A good balance would be great. Even i thought we already have one. Well, *i* thought ;)
On 03/05/2010 10:25 AM, Thomas Janssen wrote:
I can see the need and agree that maybe not every big push needs to go to N-1 releases. But not pushing 4.x.x relases to the currently "stable" N release is just plain wrong. That kills what Fedora stands for out there in the wild. To be a leading edge distribution. And dont come up again with rawhide. That's just ridiculous, because then i can run EVERY distro out there and use their rawhide/factory/cooker or whatever name they have. Leading edge doesn't stand only for "new technics adopted first".
Another thing, since you throw that links about package_update_guidelines around, some maintainers should also check what software is my software built against and dont push broken software without testing to stable because of that "mistake" ;)
Just to remind anyone, if you forgot, or dont know what Fedora stands for IN REAL LIFE, you might go out and check it. It stands exactly for what you terribly fight against. And people love it exactly for that. But sure, there's always the possibility to bend over and try as hard as you can to make something without an own identity.....
I think you're making a mistake. Surely there's a fundamental distinction between a distro that has the latest packages when released and a distro that has the latest packages all the time via updates. Even if Fedora didn't push new upstream versions via updates, it'd still be a very hot leading edge distro.
Andrew.
On Fri, Mar 5, 2010 at 2:57 PM, Andrew Haley aph@redhat.com wrote:
On 03/05/2010 10:25 AM, Thomas Janssen wrote:
I can see the need and agree that maybe not every big push needs to go to N-1 releases. But not pushing 4.x.x relases to the currently "stable" N release is just plain wrong. That kills what Fedora stands for out there in the wild. To be a leading edge distribution. And dont come up again with rawhide. That's just ridiculous, because then i can run EVERY distro out there and use their rawhide/factory/cooker or whatever name they have. Leading edge doesn't stand only for "new technics adopted first".
Another thing, since you throw that links about package_update_guidelines around, some maintainers should also check what software is my software built against and dont push broken software without testing to stable because of that "mistake" ;)
Just to remind anyone, if you forgot, or dont know what Fedora stands for IN REAL LIFE, you might go out and check it. It stands exactly for what you terribly fight against. And people love it exactly for that. But sure, there's always the possibility to bend over and try as hard as you can to make something without an own identity.....
I think you're making a mistake. Surely there's a fundamental distinction between a distro that has the latest packages when released and a distro that has the latest packages all the time via updates. Even if Fedora didn't push new upstream versions via updates, it'd still be a very hot leading edge distro.
Well, no. It wouldn't be a very hot leading distro. It would be nothing more than any other distro with the same release-cycle. Sure there would be some new stuff, as we had PA as first (just an example). Though, exact that stuff annoyed a lot of users the most. And who cares for real? It's not like Sound wasn't working or there was nothing like Jack. Look at openSUSE, Mandriva, Ubuntu. They do the same good job as we do. BUT they dont push the latest packages via updates. And that's the difference for a lot of us. That's exactly the reason why a lot of us changed to Fedora. I would still stay with openSUSE if they did the same.
So i (and others who think like me), have no reason to use Fedora over one of the other mainstream Distros if Fedora is the same. And we will not get users like me if we dont offer that. Sure, there might be people who dont give a darn about people like me.
As said, if you ask who's the better Ubuntu, it will always be Ubuntu.
If you ask me, i say, have a face, have a character and offer something the others dont. Fedora is exactly that right now.
* Thomas Janssen [05/03/2010 17:03] :
If you ask me, i say, have a face, have a character and offer something the others dont. Fedora is exactly that right now.
We're left with the problem that what Fedora is right now isn't working (massive amounts of updates that our users have to download, daily composes that take 8 hours, ...).
Emmanuel
On 03/05/2010 03:25 PM, Thomas Janssen wrote:
On Fri, Mar 5, 2010 at 2:57 PM, Andrew Haley aph@redhat.com wrote:
On 03/05/2010 10:25 AM, Thomas Janssen wrote:
I can see the need and agree that maybe not every big push needs to go to N-1 releases. But not pushing 4.x.x relases to the currently "stable" N release is just plain wrong. That kills what Fedora stands for out there in the wild. To be a leading edge distribution. And dont come up again with rawhide. That's just ridiculous, because then i can run EVERY distro out there and use their rawhide/factory/cooker or whatever name they have. Leading edge doesn't stand only for "new technics adopted first".
Another thing, since you throw that links about package_update_guidelines around, some maintainers should also check what software is my software built against and dont push broken software without testing to stable because of that "mistake" ;)
Just to remind anyone, if you forgot, or dont know what Fedora stands for IN REAL LIFE, you might go out and check it. It stands exactly for what you terribly fight against. And people love it exactly for that. But sure, there's always the possibility to bend over and try as hard as you can to make something without an own identity.....
I think you're making a mistake. Surely there's a fundamental distinction between a distro that has the latest packages when released and a distro that has the latest packages all the time via updates. Even if Fedora didn't push new upstream versions via updates, it'd still be a very hot leading edge distro.
Well, no. It wouldn't be a very hot leading distro. It would be nothing more than any other distro with the same release-cycle.
Assuming that other distros were packaging all of the exact same releases on the exact same release cycle, yes, obviously. However, I don't believe that a distro which always immediately pushed every new upstream release of everything would be very useful: it'd basically be like trying to use rawhide all the time.
I suspect that the Fedora policy, as stated, makes the most sense for most people who use Fedora. There is no rule against pushing new package releases to updates, but they're not pushed unless there's a good reason. Fedora is a really good full-featured Linux distro with an agrressive release cycle, even without a continuous drinking-from-a-firehose updates policy.
So i (and others who think like me), have no reason to use Fedora over one of the other mainstream Distros if Fedora is the same. And we will not get users like me if we dont offer that. Sure, there might be people who dont give a darn about people like me.
Well, that's a rather specialized taste.
Andrew.
On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
On 03/05/2010 03:25 PM, Thomas Janssen wrote:
Well, no. It wouldn't be a very hot leading distro. It would be nothing more than any other distro with the same release-cycle.
Assuming that other distros were packaging all of the exact same releases on the exact same release cycle, yes, obviously. However, I don't believe that a distro which always immediately pushed every new upstream release of everything would be very useful: it'd basically be like trying to use rawhide all the time.
Agreed, current rawhide is not consumable or very appealing as a platform to run.
I suspect that the Fedora policy, as stated, makes the most sense for most people who use Fedora. There is no rule against pushing new package releases to updates, but they're not pushed unless there's a good reason.
Agreed here as well. Proper emphasis on "reason" -- there should be a reason other than upstream has a new release but there's a lot of leeway for the maintainer to decide if the reason::risk ratio is okay.
Fedora is a really good full-featured Linux distro with an agrressive release cycle, even without a continuous drinking-from-a-firehose updates policy.
This is where I'm a bit confused.... AFAICS, no one has pushed for a drink-from-the-firehose policy. The fact that rawhide is basically drinking from the firehose is why people care about there being a policy for F-current that is not overly restrictive... (ie, they want something between, only security and critical bugfixes, no enhancements and rawhide)
So i (and others who think like me), have no reason to use Fedora over one of the other mainstream Distros if Fedora is the same. And
h > we will not get users like me if we dont offer that. Sure, there
might be people who dont give a darn about people like me.
Well, that's a rather specialized taste.
And since I was lost at the previous step, I wonder here what you think Thomas wants that's rather specialized. If you think it's "drink from the firehose" and that == rawhide, I agree that that's specialized. If it's semi-rolling updates, then I think that's not so specialized at all.
-Toshio
On Fri, Mar 5, 2010 at 7:07 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
On 03/05/2010 03:25 PM, Thomas Janssen wrote:
So i (and others who think like me), have no reason to use Fedora over one of the other mainstream Distros if Fedora is the same. And we will not get users like me if we dont offer that. Sure, there might be people who dont give a darn about people like me.
Well, that's a rather specialized taste.
And since I was lost at the previous step, I wonder here what you think Thomas wants that's rather specialized. If you think it's "drink from the firehose" and that == rawhide, I agree that that's specialized. If it's semi-rolling updates, then I think that's not so specialized at all.
I want semi-rolling updates :)
On Fri, 2010-03-05 at 13:07 -0500, Toshio Kuratomi wrote:
And since I was lost at the previous step, I wonder here what you think Thomas wants that's rather specialized. If you think it's "drink from the firehose" and that == rawhide, I agree that that's specialized. If it's semi-rolling updates, then I think that's not so specialized at all.
Some of us feel that the current rate of updates on our released Fedoras /is/ a firehose.
On Fri, Mar 05, 2010 at 10:27:53AM -0800, Jesse Keating wrote:
On Fri, 2010-03-05 at 13:07 -0500, Toshio Kuratomi wrote:
And since I was lost at the previous step, I wonder here what you think Thomas wants that's rather specialized. If you think it's "drink from the firehose" and that == rawhide, I agree that that's specialized. If it's semi-rolling updates, then I think that's not so specialized at all.
Some of us feel that the current rate of updates on our released Fedoras /is/ a firehose.
That's fine for some people to think but also, not what I was asking Andrew to clarify :-)
-Toshio
On 03/05/2010 06:07 PM, Toshio Kuratomi wrote:
On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
I suspect that the Fedora policy, as stated, makes the most sense for most people who use Fedora. There is no rule against pushing new package releases to updates, but they're not pushed unless there's a good reason.
Agreed here as well. Proper emphasis on "reason" -- there should be a reason other than upstream has a new release but there's a lot of leeway for the maintainer to decide if the reason::risk ratio is okay.
OK, so we are on the same page.
Fedora is a really good full-featured Linux distro with an aggressive release cycle, even without a continuous drinking-from-a-firehose updates policy.
This is where I'm a bit confused.... AFAICS, no one has pushed for a drink-from-the-firehose policy.
Really? Rajeesh K Nambiar wrote about the "latest-and-greatest, bleeding edge policy of Fedora." Thomas Janseen was arging against Rahul Sundaram's perfectly reasonable reminder of the current package update guidelines.
So i (and others who think like me), have no reason to use Fedora over one of the other mainstream Distros if Fedora is the same. And we will not get users like me if we dont offer that. Sure, there might be people who dont give a darn about people like me.
Well, that's a rather specialized taste.
And since I was lost at the previous step, I wonder here what you think Thomas wants that's rather specialized. If you think it's "drink from the firehose" and that == rawhide, I agree that that's specialized. If it's semi-rolling updates, then I think that's not so specialized at all.
Perhaps not, but disagreeing with such an eminently sensible message as Rahul's makes me wonder.
Andrew.
On Sat, Mar 6, 2010 at 12:48 PM, Andrew Haley aph@redhat.com wrote:
On 03/05/2010 06:07 PM, Toshio Kuratomi wrote:
On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
Well, that's a rather specialized taste.
And since I was lost at the previous step, I wonder here what you think Thomas wants that's rather specialized. If you think it's "drink from the firehose" and that == rawhide, I agree that that's specialized. If it's semi-rolling updates, then I think that's not so specialized at all.
Perhaps not, but disagreeing with such an eminently sensible message as Rahul's makes me wonder.
Perhaps you got only the half of the message, and perhaps because i wrote it especially to Rahul ;)
Anyways. I think it's clear now.
On Fri, 2010-03-05 at 11:25 +0100, Thomas Janssen wrote:
I read about regressions all the time in KDE releases, over and over again. What's a regression you Rahul have faced and can you provide a BZ as well?
(snip)
The nepomuk problem some face is something that falls under, damn, that shouldn't happen, but sh!t happens. I saw a lot more and even terrible stuff happen in Fedora.
So first you claim there's no regressions, then you acknowledge a specific one and excuse it by saying 'shit happens'? And 'I saw a lot more and even terrible stuff happen in Fedora'? The whole point of the discussion is that not everyone is happy that 'shit happens', and some wish to reduce the about of 'terrible stuff' that happens in Fedora.
On Fri, Mar 5, 2010 at 5:22 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2010-03-05 at 11:25 +0100, Thomas Janssen wrote:
I read about regressions all the time in KDE releases, over and over again. What's a regression you Rahul have faced and can you provide a BZ as well?
(snip)
The nepomuk problem some face is something that falls under, damn, that shouldn't happen, but sh!t happens. I saw a lot more and even terrible stuff happen in Fedora.
So first you claim there's no regressions, then you acknowledge a specific one and excuse it by saying 'shit happens'? And 'I saw a lot more and even terrible stuff happen in Fedora'? The whole point of the discussion is that not everyone is happy that 'shit happens', and some wish to reduce the about of 'terrible stuff' that happens in Fedora.
No, i haven't claimed there are no regressions, i just pointed out that i dont like if a lot of people blow into the same horn, but haven't seen a regression themselves. That's a difference. And yes, i excused it with 'sh!t happens'. It is like that in the World, 'stuff happens'. And if it happens in the SIG we talk about it and try to not do it again. No, that doesn't mean that we think we're wrong with the updates of 4.x.x updates. It's already explained over and over again why we update KDE SC.
There are regressions. But not just in KDE. But interesting that so much people cry about KDE only. And Yes, it's always bad if terrible stuff happens. But you cant reduce *all* the stuff that happens if you constantly pester a single SIG. It's not like that the KDE SIG is the only one that makes mistakes or where stuff happens.
*sigh*
On Fri, 2010-03-05 at 17:40 +0100, Thomas Janssen wrote:
There are regressions. But not just in KDE. But interesting that so much people cry about KDE only.
I agree with that, and I said so earlier in the thread...
And Yes, it's always bad if terrible stuff happens. But you cant reduce *all* the stuff that happens if you constantly pester a single SIG. It's not like that the KDE SIG is the only one that makes mistakes or where stuff happens.
...however, that's not what's happening. No-one has made any proposal which would affect only the KDE SIG.
Adam Williamson wrote:
On Fri, 2010-03-05 at 11:25 +0100, Thomas Janssen wrote:
The nepomuk problem some face is something that falls under, damn, that shouldn't happen, but sh!t happens. I saw a lot more and even terrible stuff happen in Fedora.
So first you claim there's no regressions, then you acknowledge a specific one and excuse it by saying 'shit happens'? And 'I saw a lot more and even terrible stuff happen in Fedora'? The whole point of the discussion is that not everyone is happy that 'shit happens', and some wish to reduce the about of 'terrible stuff' that happens in Fedora.
Assuming he's talking about this problem: http://userbase.kde.org/Akonadi#Nepomuk_Indexing_Agents_have_been_Disabled then I'd argue this is not a noticeable regression for most users if it weren't for the annoying message box.
As of 4.4 (4.5 will probably need both Akonadi and Akonadi's Nepomuk integration for more stuff, but we aren't pushing 4.5 any time soon, there isn't even any alpha or beta release of it yet), if you don't happen to use some contacts-related features ("ranging from displaying upcoming birthdays, over handling free/busy lists to showing a contact photo in the message viewer" according to upstream), the only thing you'll notice is the message box. If you do use those features, the message box tries to tell you what's wrong and how to fix it (but admittedly does a very poor job of it), so there's a pretty straightforward workaround.
That said, we have acknowledged the annoyance factor (which we had underestimated) and we also had apparently underestimated the reduction in functionality from not having Nepomuk running (we thought it was only used for searches). Updates to our default settings rectifying this (by enabling Nepomuk by default) are now queued for testing: https://admin.fedoraproject.org/updates/kde-settings-4.3-18 https://admin.fedoraproject.org/updates/kde-settings-4.2-18
We apologize for the inconvenience and we acknowledge that we made a mistake, but still I personally think this issue has been way overblown. I've seen other annoying incomprehensible message boxes in Fedora in the past, and Window$ (which many people believe is "user friendly") is full of them.
Kevin Kofler
On Fri, Mar 5, 2010 at 1:15 PM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 10:16 AM, Rajeesh K Nambiar wrote:
Does that mean if Fedora N is released with KDE 4.x, the users get 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the latest-and-greatest, bleeding edge policy of Fedora.
If you would point me to such a "bleeding edge" policy then I could agree but I believe this is merely assumed by some and if you want the latest always you could use kde-redhat repo
I have been looking at the kde-redhat repo and I couldn't find any KDE SC 4.3+ updates. Am I missing something?
Rahul
On Fri, Mar 5, 2010 at 12:56 PM, Rajeesh K Nambiar rajeeshknambiar@gmail.com wrote:
On Fri, Mar 5, 2010 at 1:15 PM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 10:16 AM, Rajeesh K Nambiar wrote:
Does that mean if Fedora N is released with KDE 4.x, the users get 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the latest-and-greatest, bleeding edge policy of Fedora.
If you would point me to such a "bleeding edge" policy then I could agree but I believe this is merely assumed by some and if you want the latest always you could use kde-redhat repo
I have been looking at the kde-redhat repo and I couldn't find any KDE SC 4.3+ updates. Am I missing something?
In kde-redhat you can find the next version of KDE SC, means soon 4.4.1 and some new versions of, for example, amarok. But no 4.3.x packages.
On Fri, Mar 5, 2010 at 1:01 PM, Thomas Janssen thomasj@fedoraproject.org wrote:
On Fri, Mar 5, 2010 at 12:56 PM, Rajeesh K Nambiar rajeeshknambiar@gmail.com wrote:
On Fri, Mar 5, 2010 at 1:15 PM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 10:16 AM, Rajeesh K Nambiar wrote:
Does that mean if Fedora N is released with KDE 4.x, the users get 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the latest-and-greatest, bleeding edge policy of Fedora.
If you would point me to such a "bleeding edge" policy then I could agree but I believe this is merely assumed by some and if you want the latest always you could use kde-redhat repo
I have been looking at the kde-redhat repo and I couldn't find any KDE SC 4.3+ updates. Am I missing something?
In kde-redhat you can find the next version of KDE SC, means soon 4.4.1 and some new versions of, for example, amarok. But no 4.3.x packages.
Well, yeah, right now it's almost empty since 4.4.0 is already out to testing/stable. I forgot to mention that.
On Fri, Mar 5, 2010 at 5:34 PM, Thomas Janssen thomasj@fedoraproject.org wrote:
On Fri, Mar 5, 2010 at 1:01 PM, Thomas Janssen thomasj@fedoraproject.org wrote:
On Fri, Mar 5, 2010 at 12:56 PM, Rajeesh K Nambiar rajeeshknambiar@gmail.com wrote:
On Fri, Mar 5, 2010 at 1:15 PM, Rahul Sundaram metherid@gmail.com wrote:
On 03/05/2010 10:16 AM, Rajeesh K Nambiar wrote:
Does that mean if Fedora N is released with KDE 4.x, the users get 4.x+1 only in Fedora N+1? It sounds diagonally opposite to the latest-and-greatest, bleeding edge policy of Fedora.
If you would point me to such a "bleeding edge" policy then I could agree but I believe this is merely assumed by some and if you want the latest always you could use kde-redhat repo
I have been looking at the kde-redhat repo and I couldn't find any KDE SC 4.3+ updates. Am I missing something?
In kde-redhat you can find the next version of KDE SC, means soon 4.4.1 and some new versions of, for example, amarok. But no 4.3.x packages.
Well, yeah, right now it's almost empty since 4.4.0 is already out to testing/stable. I forgot to mention that.
I must be looking at the wrong places then... I could find no 4.4+ RPMs either in one of the mirrors: http://apt.de.kde-redhat.org/kde-redhat/fedora/12/i386/unstable/RPMS/
-- LG Thomas
Dubium sapientiae initium
Rajeesh K Nambiar wrote:
I must be looking at the wrong places then... I could find no 4.4+ RPMs either in one of the mirrors: http://apt.de.kde-redhat.org/kde-redhat/fedora/12/i386/unstable/RPMS/
4.4.0 is already an official update, why would kde-redhat carry it?
4.4.1 is not built yet. It will probably be put into kde-redhat testing in addition to the official updates-testing (the exact same binary packages) for those who don't want to easily test it without pulling in all of updates-testing.
Prereleases of 4.5 haven't been released by upstream yet. When we start working on 4.5, we will import it to Rawhide first, and kde-redhat unstable will get builds of the same stuff.
Kevin Kofler
On Fri, Mar 5, 2010 at 7:37 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Rajeesh K Nambiar wrote:
I must be looking at the wrong places then... I could find no 4.4+ RPMs either in one of the mirrors: http://apt.de.kde-redhat.org/kde-redhat/fedora/12/i386/unstable/RPMS/
4.4.0 is already an official update, why would kde-redhat carry it?
4.4.1 is not built yet. It will probably be put into kde-redhat testing in addition to the official updates-testing (the exact same binary packages) for those who don't want to easily test it without pulling in all of updates-testing.
Prereleases of 4.5 haven't been released by upstream yet. When we start working on 4.5, we will import it to Rawhide first, and kde-redhat unstable will get builds of the same stuff.
Thanks for the clarification, Kevin.
Kevin Kofler
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I wrote:
4.4.1 is not built yet. It will probably be put into kde-redhat testing in addition to the official updates-testing (the exact same binary packages) for those who don't want to easily test it without pulling in all of updates-testing.
Uh, I butchered that sentence. I mean: 4.4.1 is not built yet. It will probably be put into kde-redhat testing in addition to the official updates-testing (the exact same binary packages) for those who don't want to enable the whole updates-testing, so they can easily test it without pulling in all of updates-testing.
Kevin Kofler
On Thu, Mar 4, 2010 at 11:20 AM, Rex Dieter wrote:
Like most any group making hard decisions, the KDE SIG bases them on the best information available. Fact is, we extensively tested this new version for over a month, and every serious issue/blocker that was reported or identified was addressed prior to releasing this.
Unfortunately, it seems there were more problems than what we were aware of when the decision was made to do the 4.4.0 (stable) update. Yeah, that sucks.
Maybe 1 month of testing was not enough. We should have left it in update-testing for 2 months, 3 months... This would give more time to the "curious" users to test KDE. This is why I defend the extensive use of updates-testing idea. 4.x.0 releases stay in updates-testing for a month. It is never pushed to stable. After a month 4.x.1 is released with bugfixes. That one goes to testing, stays there for about another month and then it will be pushed to stable. x.0.0 releases wait 1 full Fedora release to get in (speaking of 4.0.0 if anyone didn't notice.).
There is one more thing. Very important thing. We have been pushing KDE releases asap so far, and although it hurt me at times (at school and at work), I like it. I don't blame people who don't. Here is the thing: The bugs need to be reported most of the time to get fixed. Fedora has been a pioneer in KDE development in this sense. If we don't push 4.x.0 releases to stable, the 4.x.1 will be more buggy, since not many distros do kde 4.x.0 updates to their stable releases. Someone has to make some sort of sacrifice but I cannot come up with a good-for-all resolution for this issue.
Orcan
Orcan Ogetbil (oget.fedora@gmail.com) said:
There is one more thing. Very important thing. We have been pushing KDE releases asap so far, and although it hurt me at times (at school and at work), I like it. I don't blame people who don't. Here is the thing: The bugs need to be reported most of the time to get fixed. Fedora has been a pioneer in KDE development in this sense. If we don't push 4.x.0 releases to stable, the 4.x.1 will be more buggy, since not many distros do kde 4.x.0 updates to their stable releases. Someone has to make some sort of sacrifice but I cannot come up with a good-for-all resolution for this issue.
If we are going down the road of providing absolute-latest-versions on older releases, perhaps not pushing it to prior releases until it's actually been in wide use on the next release? So, you have, for example:
- new version 4.6 -> push it to rawhide, get testing -> get new Fedora release with that version --> get *even more testing*, make needed fixes
And only *then* do you push it to the prior releases, once it's actually proven that it's not going to break things for the widest group of users. It lets you not only use the rawhide adopters, who expect major change, but the next-release early adopters, who also expect adjustments on moving to a next major release.
Bill
Bill Nottingham wrote:
If we are going down the road of providing absolute-latest-versions on older releases, perhaps not pushing it to prior releases until it's actually been in wide use on the next release? So, you have, for example:
- new version 4.6
-> push it to rawhide, get testing -> get new Fedora release with that version --> get *even more testing*, make needed fixes
And only *then* do you push it to the prior releases, once it's actually proven that it's not going to break things for the widest group of users. It lets you not only use the rawhide adopters, who expect major change, but the next-release early adopters, who also expect adjustments on moving to a next major release.
The problem is that this translates to a LOT more work for us. By pushing to both releases at the same time, we can build things together, do the buildroot overrides together, queue things to testing together, promote them to stable together. Doing things in the staged way would mean almost twice the workload (especially in terms of time expense) for us. :-(
In addition, we already got 4.4.0 out only barely before 4.4.1 was released. If we had staged it as you propose, we'd now be stuck with having to do one of 2 things: A. push 4.4.0 into F11 and 4.4.1 into F12. This means: - we'd be working on 2 different releases at the same time, which would stretch our resources quite a lot, - F11 would end up with a KDE "update" which is already obsolete when pushed, and in particular includes known bugs which are fixed in the bugfix release that 4.4.1 is. B. skip 4.4.0 in F11 and go straight to 4.4.1. This means: - we'd be shipping the same release, but in one case as a big update with many other related packages to update, and in another case as a bugfix release. This also means 2 very different updates to prepare at the same time and would also stretch our resources quite thin. - the F11 update would either not be staged compared to the F12 4.4.1 one, or the wait for 4.4 would be even longer than a month.
Support would also get more complicated with the 2 current versions in circulation simultaneously. Right now, if something's fixed in F12, it's also fixed in F11 and vice-versa, and we can in general expect our users to all run the same KDE (unless they just haven't updated yet).
And finally, those F11 users who want 4.4 would feel treated like second- class citizens for having to wait longer, those who don't want it just don't want it at all, staged or not.
So I don't think staged updates are a workable solution (there's a reason almost no maintainer works that way at this time).
Kevin Kofler
On Fri, Mar 05, 2010 at 12:55:23PM -0500, Bill Nottingham wrote:
Orcan Ogetbil (oget.fedora@gmail.com) said:
There is one more thing. Very important thing. We have been pushing KDE releases asap so far, and although it hurt me at times (at school and at work), I like it. I don't blame people who don't. Here is the thing: The bugs need to be reported most of the time to get fixed. Fedora has been a pioneer in KDE development in this sense. If we don't push 4.x.0 releases to stable, the 4.x.1 will be more buggy, since not many distros do kde 4.x.0 updates to their stable releases. Someone has to make some sort of sacrifice but I cannot come up with a good-for-all resolution for this issue.
If we are going down the road of providing absolute-latest-versions on older releases, perhaps not pushing it to prior releases until it's actually been in wide use on the next release? So, you have, for example:
- new version 4.6
-> push it to rawhide, get testing -> get new Fedora release with that version --> get *even more testing*, make needed fixes
And only *then* do you push it to the prior releases, once it's actually proven that it's not going to break things for the widest group of users. It lets you not only use the rawhide adopters, who expect major change, but the next-release early adopters, who also expect adjustments on moving to a next major release.
There's multiple ways this could look since we have multiple repos. Does this look like you are imagining?
1) Build for rawhide, F-14, F-13 2) Push to updates-testing on F-14 and F-13 2.1) Testing period. If bugs are found and fixed go back to (1) 3) Push F-14 to updates/release 3.1) Testing period. If bugs are found and fixed go back to (1) 4) Push to F-13 updates.
-Toshio
Toshio Kuratomi (a.badger@gmail.com) said:
If we are going down the road of providing absolute-latest-versions on older releases, perhaps not pushing it to prior releases until it's actually been in wide use on the next release? So, you have, for example:
- new version 4.6
-> push it to rawhide, get testing -> get new Fedora release with that version --> get *even more testing*, make needed fixes
And only *then* do you push it to the prior releases, once it's actually proven that it's not going to break things for the widest group of users. It lets you not only use the rawhide adopters, who expect major change, but the next-release early adopters, who also expect adjustments on moving to a next major release.
There's multiple ways this could look since we have multiple repos. Does this look like you are imagining?
- Build for rawhide, F-14, F-13
- Push to updates-testing on F-14 and F-13
2.1) Testing period. If bugs are found and fixed go back to (1) 3) Push F-14 to updates/release 3.1) Testing period. If bugs are found and fixed go back to (1) 4) Push to F-13 updates.
Something like that, yes. The idea is that before it goes out to a prior release, we make sure it's been proven with some level of stability on a new release first.
Bill
Mike McGrath wrote:
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
Of course we're sorry for the issues caused by our update, and we're doing what we can to resolve them as quickly as possible. (For example, we will be pushing a kde-settings update to enable Nepomuk by default so that scary Akonadi warning goes away. Hopefully that won't cause more chaos, crossing fingers. The resource-eating Strigi file indexing will stay disabled by default in F11 and F12, of course.)
It's just that it's a more productive use of everyone's time to help fixing the issues instead of complaining about what's already done.
Kevin Kofler
On Thu, 4 Mar 2010, Kevin Kofler wrote:
Mike McGrath wrote:
Alternatively, the KDE SIG could stop ignoring the problems that were caused this week by the updates they released. Even an "I'm sorry I broke your desktop" would go a long way. The update the busted my desktop happened on a pretty vanilla install, I suspect lots of users experienced issues.
Of course we're sorry for the issues caused by our update, and we're doing what we can to resolve them as quickly as possible. (For example, we will be pushing a kde-settings update to enable Nepomuk by default so that scary Akonadi warning goes away. Hopefully that won't cause more chaos, crossing fingers. The resource-eating Strigi file indexing will stay disabled by default in F11 and F12, of course.)
It's just that it's a more productive use of everyone's time to help fixing the issues instead of complaining about what's already done.
Sorry, i guess I wasn't being as clear as I could have been.
I'm not complaining about what's already done.
I'm complaining because it is going to happen again. I just feel the issues that have come up could not be spelled out better then they have and I think the KDE sig has learned no lessons at all from it.
-Mike
On Thursday 04 March 2010 15:30:43 Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
Third party repos are highway to hell unfortunately. Ask former OpenSuse users :( Of course - it's one of solutions.
I would argue having this within Fedora infrastructure would be better as it would prevent proliferation of third-party repos replacing Fedora packages and the resulting compatibility issues (see e.g. the chaos we're having for RHEL with third-party repositories replacing official packages with newer versions and the resulting dependency hell) and as it would also provide a place for new versions of less commonly-used applications.
So the thing is that KDE SIG wants to prevent any other activity and keep the strings in own hands. That's why nobody can't enjoy the upstream's intended stability in bugfix releases and plan major upgrades.
If someone wants to fork, whatever, let them do it. That's why Fedora moves to the git, to make it easier.
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
What you've just proved could have been enough for some companies trying to run Fedora on their employees desktops and they probably think that they've seen enough. TCO is rising too high when you cannot do sane stable release updates.
Fedora is not for companies - with one year of lifetime it's not very well suited for any long-term deployment. Use Cent OS - it's not I don't want to see Fedora there, it's just reality. And Cent OS is just older and more stable Fedora...
In other words, SIG's current policy is doing more harm than good for Fedora.
But I think having yet another thread about update policies will be frowned upon by the moderators. Instead, let's please think about repairing this breakage now that it happened, i.e. get bug reports filed etc.
Yes, let's fix the bug instead the policy that caused it in the first place, sigh.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
On Thu, Mar 4, 2010 at 3:46 PM, Jaroslav Reznik jreznik@redhat.com wrote:
On Thursday 04 March 2010 15:30:43 Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
Third party repos are highway to hell unfortunately. Ask former OpenSuse users :( Of course - it's one of solutions.
Yes (former/still some installations, openSUSE user here), third party repos can be a hell. They are definitely not for beginners or i-dont-care users.
On Thursday 04 March 2010 15:58:32 Thomas Janssen wrote:
On Thu, Mar 4, 2010 at 3:46 PM, Jaroslav Reznik jreznik@redhat.com wrote:
On Thursday 04 March 2010 15:30:43 Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
current stable release nor support an official backports repo, an unofficial one will no doubt spring up, or an existing unofficial repo will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
Third party repos are highway to hell unfortunately. Ask former OpenSuse users
:( Of course - it's one of solutions.
Yes (former/still some installations, openSUSE user here), third party repos can be a hell. They are definitely not for beginners or i-dont-care users.
These repos are not intended for beginners/i-dont-care users but it's hell even for advanced users - it just screw system... Even I try not to mess with RPM fussion but it's still needed :(
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
will pick up that role (for KDE, kde-redhat stable would probably be revived, currently it's mostly empty for Fedora as the kind of stuff which would be in there is usually just pushed as official Fedora updates).
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
Third party repos are highway to hell unfortunately. Ask former OpenSuse users
These repos are not intended for beginners/i-dont-care users but it's hell even for advanced users - it just screw system... Even I try not to mess with RPM fussion but it's still needed :(
You're being overdramatic here. It's the same repo that is being used to test latest KDE stuff right now before it goes to rawhide and to the releases. It's built by same people who make actual releases. It's KDE team's repo, it's Rex's old repo/project before KDE got proper status in Fedora.
How you could use its problems (that apparently don't even exist) as an argument and reason to cause problems for people who just want to use those kde bugfix releases in old, stable Fedora release?
Tuju
-- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
Go ahead, make that to your kde-hardcore-followers-repo. In my understanding, that's what it has been for past years already anyway.
Third party repos are highway to hell unfortunately.
Quite interesting statement from the KDE SIG who runs that third party repo.
Fedora is not for companies -
Even accepting the release cycle and official release policies?
I'd concentrate defining *what* the Fedora is, and sticking on it. Let the consumers decide does it suit them or not.
Tuju
-- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating
Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
I would argue having this within Fedora infrastructure would be better as it would prevent proliferation of third-party repos replacing Fedora packages and the resulting compatibility issues (see e.g. the chaos we're having for RHEL with third-party repositories replacing official packages with newer versions and the resulting dependency hell) and as it would also provide a place for new versions of less commonly-used applications.
So the thing is that KDE SIG wants to prevent any other activity and keep the strings in own hands.
Huh? What I was saying is that it's not a good idea if you have: * kde-redhat replacing Fedora's Qt and KDE packages with newer stable versions * repo X replacing Fedora's kernel packages with newer stable versions * repo Y replacing Fedora's some-library packages with newer stable versions * repo Z replacing Fedora's some-application packages with newer stable versions etc., and users who want to be up to date having all these repos enabled, when the repository maintainers didn't test them together (or they did, in which case the people who're trying to enable only, say, repo Y, are the ones getting screwed).
Having one central backports (or just updates as now) repository prevents those compatibility issues.
That's why nobody can't enjoy the upstream's intended stability in bugfix releases and plan major upgrades.
You keep saying that, yet you have provided no evidence of such a stance from upstream. KDE upstream actually has no policy on what versions should be pushed as updates in what distros, it's a distro decision!
If someone wants to fork, whatever, let them do it. That's why Fedora moves to the git, to make it easier.
The issue is not forking the specfiles, it's mixing the repos and the resulting dependency hell.
That said, IMHO the best solution is still to have this stuff in the official updates. But it's true that the kind of issues some users are having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't shown up during testing or it would have been considered a blocker.
What you've just proved could have been enough for some companies trying to run Fedora on their employees desktops and they probably think that they've seen enough. TCO is rising too high when you cannot do sane stable release updates.
Who says they would have seen that issue at all? You're the first one to report this particular issue.
In other words, SIG's current policy is doing more harm than good for Fedora.
Not necessarily. There has also been some very positive feedback for the KDE 4.4 updates, and some people are using Fedora BECAUSE such updates get pushed.
But I think having yet another thread about update policies will be frowned upon by the moderators. Instead, let's please think about repairing this breakage now that it happened, i.e. get bug reports filed etc.
Yes, let's fix the bug instead the policy that caused it in the first place, sigh.
It's too late to undo the update now, it already got pushed (reverting would break a lot more things, KDE does not support downgrades).
So the only productive thing to do now is to fix the bug. Complaining about it serves nobody.
So please provide the details required to actually FIX the bug! I.e. file a bug report and provide the output of "akonadictl start" Rex asked for.
Kevin Kofler
On Thu, 4 Mar 2010, Kevin Kofler wrote:
That's why nobody can't enjoy the upstream's intended stability in bugfix releases and plan major upgrades.
You keep saying that, yet you have provided no evidence of such a stance from upstream. KDE upstream actually has no policy on what versions should be pushed as updates in what distros, it's a distro decision!
a) how users are supposed to consume those bugfix releases only, when you push feature release in the middle of working week?
b) why those different releases exist in the first place, if there is no intention to differentiate them?
That is, there wouldn't be need for third release number, we coul just have kde-4.28 now.
Speaking of distro decision, you mean that when FESCO decides this to stop, KDE SIG will stop it too. That's good.
Tuju
-- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating
Juha Tuomala wrote:
a) how users are supposed to consume those bugfix releases only, when you push feature release in the middle of working week?
What bugfix releases would we be supposed to push? There are no further 4.3.x releases.
b) why those different releases exist in the first place, if there is no intention to differentiate them?
Because they are needed due to KDE's own development method and schedule? That doesn't imply any assumption about what distros package.
And in fact I'd even argue KDE upstream expects users to be using 4.4.x now, not 4.3.x, or they'd continue supporting 4.3.x with bugfix releases.
Speaking of distro decision, you mean that when FESCO decides this to stop, KDE SIG will stop it too. That's good.
If FESCo forces us to stop, what else could we do? We're part of Fedora and as such we do, and have to, follow Fedora policies. But I'm strongly opposed to such a distrowide policy.
Kevin Kofler
On Thu, 4 Mar 2010, Kevin Kofler wrote:
What bugfix releases would we be supposed to push? There are no further 4.3.x releases.
Nothing, if that's the case.
In case there is a major security hole and they only fix it in SCM and notify about it without making a release - I expect you to add that patch to spec and make a new RPM release.
Tuju
-- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating
Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
What bugfix releases would we be supposed to push? There are no further 4.3.x releases.
Nothing, if that's the case.
That means bugs will no longer be fixed, is that a price we want to pay just to avoid the small risk of regressions?
Kevin Kofler
On 03/04/2010 10:15 AM, Kevin Kofler wrote:
In other words, SIG's current policy is doing more harm than good for Fedora.
Not necessarily. There has also been some very positive feedback for the KDE 4.4 updates, and some people are using Fedora BECAUSE such updates get pushed.
I agree with Kevin that timely software upgrades in Fedora are a GOOD thing. The problem is not updates---it's the QA. It just should not happen that updates fail to even start up out of the box. I recognize that sometimes the problem is caused by the specific system configuration, but I have first-hand examples where the app was just plain broken. The dilemma of course is what to do in such case: currently it's either shipping the app or taking it out of the distro.
Perhaps there should be a RPM property that flagged apps with known major bugs, so that the end users could chose between
- always updating everything and dealing with breakage later - updating only security fixes - updating only security fixes and 'no-known-defects' apps
Such choice would be a global user-settable system setting, I presume. Perhaps there could be a separate setting per package group, because it would make sense to want the latest versions of engineering apps, while leaving email and desktop enough alone.
On Thu, 2010-03-04 at 14:57 +0100, Kevin Kofler wrote:
Rahul Sundaram wrote:
Whether it would be a separate backports repo or merely some more conservativeness in our update stream
FWIW, for stuff like KDE, if we don't allow new feature upgrades even in the current stable release nor support an official backports repo, an unofficial one will no doubt spring up
yup, this is very likely. One reason Mandriva's backports repository was initiated was because, when MDV allowed only conservative updates and had no official facility for adventurous updates, a forest of third-party repos offering new versions of things sprung up. Obviously this led to confusion for people doing user support ('wait, exactly *whose* KDE 4.3 packages were you running again?') and all sorts of fun with incompatibilities between the third party repos.
On 03/04/2010 01:49 PM, Adam Williamson wrote:
On Thu, 2010-03-04 at 14:57 +0100, Kevin Kofler wrote:
Rahul Sundaram wrote:
Whether it would be a separate backports repo or merely some more conservativeness in our update stream
FWIW, for stuff like KDE, if we don't allow new feature upgrades even in the current stable release nor support an official backports repo, an unofficial one will no doubt spring up
yup, this is very likely. One reason Mandriva's backports repository was initiated was because, when MDV allowed only conservative updates and had no official facility for adventurous updates, a forest of third-party repos offering new versions of things sprung up. Obviously this led to confusion for people doing user support ('wait, exactly *whose* KDE 4.3 packages were you running again?') and all> sorts of fun with incompatibilities between the third party repos.
Just playing devil's advocate here - what's the virtue of trying to avoid separate repos? It seems like there's a false dichotomy (trichotomy?) going on here, where our choices are:
1) this is in the main Fedora(tm) repo 2) we have a special repo for updates vs upgrades, each against stable 3) A free for all of third party repos hosted at various different places with huge conflicts and no coöperation whatsoever. Repos everywhere, dogs and cats living together, Cain has been marked and kicked out of the garden, total chaos.
As a little gedankenexperiment, let's explore for a second a 4th option: Fedora-blessed/hosted/sponsored/whatever repos for things that we don't feel should be mandated on users, but which some users may want and some maintainers want to be able to provide. A little bit of all three - including a built-in need to be minimalist in construction, so as to avoid conflict nightmares, but at the same time freedom to say "here's a new major version of this, since we _know_ that's what you're looking for if you've got this repo enabled".
Obviously this would require some tools work, but isn't it worth considering?
On Thu, 2010-03-04 at 16:19 -0500, Peter Jones wrote:
yup, this is very likely. One reason Mandriva's backports repository was initiated was because, when MDV allowed only conservative updates and had no official facility for adventurous updates, a forest of third-party repos offering new versions of things sprung up. Obviously this led to confusion for people doing user support ('wait, exactly *whose* KDE 4.3 packages were you running again?') and all> sorts of fun with incompatibilities between the third party repos.
Just playing devil's advocate here - what's the virtue of trying to avoid separate repos? It seems like there's a false dichotomy (trichotomy?) going on here, where our choices are:
- this is in the main Fedora(tm) repo
- we have a special repo for updates vs upgrades, each against stable
- A free for all of third party repos hosted at various different places with huge conflicts and no coöperation whatsoever. Repos everywhere, dogs and cats living together, Cain has been marked and kicked out of the garden, total chaos.
As a little gedankenexperiment, let's explore for a second a 4th option: Fedora-blessed/hosted/sponsored/whatever repos for things that we don't feel should be mandated on users, but which some users may want and some maintainers want to be able to provide. A little bit of all three - including a built-in need to be minimalist in construction, so as to avoid conflict nightmares, but at the same time freedom to say "here's a new major version of this, since we _know_ that's what you're looking for if you've got this repo enabled".
Obviously this would require some tools work, but isn't it worth considering?
What does option 4 provide over option 2?
In fact, how is it even functionally different? 'Fedora' repositories are effectively nothing more than 'blessed' repositories anyway, given the considerable powers granted to maintainers.
On Thu, 2010-03-04 at 13:28 -0800, Adam Williamson wrote:
As a little gedankenexperiment, let's explore for a second a 4th option: Fedora-blessed/hosted/sponsored/whatever repos for things that we don't feel should be mandated on users, but which some users may want and some maintainers want to be able to provide. A little bit of all three - including a built-in need to be minimalist in construction, so as to avoid conflict nightmares, but at the same time freedom to say "here's a new major version of this, since we _know_ that's what you're looking for if you've got this repo enabled".
Obviously this would require some tools work, but isn't it worth considering?
What does option 4 provide over option 2?
In fact, how is it even functionally different? 'Fedora' repositories are effectively nothing more than 'blessed' repositories anyway, given the considerable powers granted to maintainers.
To expand a bit, my personal opinion is that a single 'blessed' repository makes more sense than a framework for the provision of multiple 'semi-blessed' repositories; the latter provides no significant benefit over the former, while making it much harder to ensure adherence to basic guidelines, and repository coherence. We already have systems for checking common guideline compliance problems and things like dependency issues within a single repository; we don't have tools for doing this across a bunch of separate quasi-independent repos.
On 03/04/2010 04:36 PM, Adam Williamson wrote:
On Thu, 2010-03-04 at 13:28 -0800, Adam Williamson wrote:
As a little gedankenexperiment, let's explore for a second a 4th option: Fedora-blessed/hosted/sponsored/whatever repos for things that we don't feel should be mandated on users, but which some users may want and some maintainers want to be able to provide. A little bit of all three - including a built-in need to be minimalist in construction, so as to avoid conflict nightmares, but at the same time freedom to say "here's a new major version of this, since we _know_ that's what you're looking for if you've got this repo enabled".
Obviously this would require some tools work, but isn't it worth considering?
What does option 4 provide over option 2?
In fact, how is it even functionally different? 'Fedora' repositories are effectively nothing more than 'blessed' repositories anyway, given the considerable powers granted to maintainers.
To expand a bit, my personal opinion is that a single 'blessed' repository makes more sense than a framework for the provision of multiple 'semi-blessed' repositories; the latter provides no significant benefit over the former, while making it much harder to ensure adherence to basic guidelines, and repository coherence.
To expand a bit, that's the point - we don't necessarily have to ensure such strict adherence to (some) guidelines or repository coherence. Obviously responsible maintainers/SIGs need to do so, but it isn't necessarily something Fedora the organization needs to do for every repo relating to every other repo. Whereas right now, it is something we must guarantee strongly (and haven't always done a great job of.)
We already have systems for checking common guideline compliance problems and things like dependency issues within a single repository; we don't have tools for doing this across a bunch of separate quasi-independent repos.
Do you really think making repoclosure do its thing over a group of repos instead of a single repo is a mountainous task? Yes, obviously we'd have to change some tools. That's why I said "Obviously this would require some tools work".
On Thu, 2010-03-04 at 16:43 -0500, Peter Jones wrote:
We already have systems for checking common guideline compliance problems and things like dependency issues within a single repository; we don't have tools for doing this across a bunch of separate quasi-independent repos.
Do you really think making repoclosure do its thing over a group of repos instead of a single repo is a mountainous task? Yes, obviously we'd have to change some tools. That's why I said "Obviously this would require some tools work".
My point was more that if there doesn't seem to be any particular advantage of the 'forest-of-separate-repos' approach, it's work for no gain.
I see your point about providing multiple repos for some projects...I'm not sure whether it's something that would turn out to be terribly useful in practice, but hey, maybe we should ask some of the bigger SIGs and see what they think.
On 03/04/2010 04:28 PM, Adam Williamson wrote:
On Thu, 2010-03-04 at 16:19 -0500, Peter Jones wrote:
yup, this is very likely. One reason Mandriva's backports repository was initiated was because, when MDV allowed only conservative updates and had no official facility for adventurous updates, a forest of third-party repos offering new versions of things sprung up. Obviously this led to confusion for people doing user support ('wait, exactly *whose* KDE 4.3 packages were you running again?') and all> sorts of fun with incompatibilities between the third party repos.
Just playing devil's advocate here - what's the virtue of trying to avoid separate repos? It seems like there's a false dichotomy (trichotomy?) going on here, where our choices are:
- this is in the main Fedora(tm) repo
- we have a special repo for updates vs upgrades, each against stable
- A free for all of third party repos hosted at various different places with huge conflicts and no coöperation whatsoever. Repos everywhere, dogs and cats living together, Cain has been marked and kicked out of the garden, total chaos.
As a little gedankenexperiment, let's explore for a second a 4th option: Fedora-blessed/hosted/sponsored/whatever repos for things that we don't feel should be mandated on users, but which some users may want and some maintainers want to be able to provide. A little bit of all three - including a built-in need to be minimalist in construction, so as to avoid conflict nightmares, but at the same time freedom to say "here's a new major version of this, since we _know_ that's what you're looking for if you've got this repo enabled".
Obviously this would require some tools work, but isn't it worth considering?
What does option 4 provide over option 2?
In fact, how is it even functionally different? 'Fedora' repositories are effectively nothing more than 'blessed' repositories anyway, given the considerable powers granted to maintainers.
Option two is one more repo for all "updates". Which may be well and good, but might also be less interesting than a more general approach. In #4, what I'm suggesting is essentially the possibility of a SIG having overlay repos for whatever distro version(s) they want; they could be experimental, they could be for upgrades that don't conform to a more strict update policy, it could be for things even *I* haven't thought of yet ;)
On 03/05/2010 03:09 AM, Peter Jones wrote:
Option two is one more repo for all "updates". Which may be well and good, but might also be less interesting than a more general approach. In #4, what I'm suggesting is essentially the possibility of a SIG having overlay repos for whatever distro version(s) they want; they could be experimental, they could be for upgrades that don't conform to a more strict update policy, it could be for things even *I* haven't thought of yet ;)
Is this what you had in mind? http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
Rahul
On 03/04/2010 04:44 PM, Rahul Sundaram wrote:
On 03/05/2010 03:09 AM, Peter Jones wrote:
Option two is one more repo for all "updates". Which may be well and good, but might also be less interesting than a more general approach. In #4, what I'm suggesting is essentially the possibility of a SIG having overlay repos for whatever distro version(s) they want; they could be experimental, they could be for upgrades that don't conform to a more strict update policy, it could be for things even *I* haven't thought of yet ;)
Is this what you had in mind? http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
It's very similar, but not quite the same, for a couple of reasons. To wit, Jesse's proposal mostly seems to focus on the repos being somewhat transient - "Bob wants a repo to test something" - whereas I'm discussing a longer-term purpose. Also, his is on a individual level, whereas what I'm discussing would be more at a SIG level. That in some sense may make implementation somewhat easier, by putting a damper on the rate at which they need to be created and destroyed, and also might include some oversight as to whether creating it is really such a good idea - but making it a "is this completely bogus" sort of choice, rather than a "does this fit in to our rigorous policies" kind of decision. This would also help avoid the option-overload that comes with #3 on my original example list.
On Thu, 2010-03-04 at 17:02 -0500, Peter Jones wrote:
On 03/04/2010 04:44 PM, Rahul Sundaram wrote:
On 03/05/2010 03:09 AM, Peter Jones wrote:
Option two is one more repo for all "updates". Which may be well and good, but might also be less interesting than a more general approach. In #4, what I'm suggesting is essentially the possibility of a SIG having overlay repos for whatever distro version(s) they want; they could be experimental, they could be for upgrades that don't conform to a more strict update policy, it could be for things even *I* haven't thought of yet ;)
Is this what you had in mind? http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
It's very similar, but not quite the same, for a couple of reasons. To wit, Jesse's proposal mostly seems to focus on the repos being somewhat transient - "Bob wants a repo to test something" - whereas I'm discussing a longer-term purpose. Also, his is on a individual level, whereas what I'm discussing would be more at a SIG level. That in some sense may make implementation somewhat easier, by putting a damper on the rate at which they need to be created and destroyed, and also might include some oversight as to whether creating it is really such a good idea - but making it a "is this completely bogus" sort of choice, rather than a "does this fit in to our rigorous policies" kind of decision. This would also help avoid the option-overload that comes with #3 on my original example list.
Peter's characterization is correct, however if we had KoPeRs, it's not that hard to expand it to SIG level repos of a less transient nature. The same base work has to be done for either case.
On 03/04/2010 05:13 PM, Jesse Keating wrote:
On Thu, 2010-03-04 at 17:02 -0500, Peter Jones wrote:
On 03/04/2010 04:44 PM, Rahul Sundaram wrote:
On 03/05/2010 03:09 AM, Peter Jones wrote:
Option two is one more repo for all "updates". Which may be well and good, but might also be less interesting than a more general approach. In #4, what I'm suggesting is essentially the possibility of a SIG having overlay repos for whatever distro version(s) they want; they could be experimental, they could be for upgrades that don't conform to a more strict update policy, it could be for things even *I* haven't thought of yet ;)
Is this what you had in mind? http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
It's very similar, but not quite the same, for a couple of reasons. To wit, Jesse's proposal mostly seems to focus on the repos being somewhat transient - "Bob wants a repo to test something" - whereas I'm discussing a longer-term purpose. Also, his is on a individual level, whereas what I'm discussing would be more at a SIG level. That in some sense may make implementation somewhat easier, by putting a damper on the rate at which they need to be created and destroyed, and also might include some oversight as to whether creating it is really such a good idea - but making it a "is this completely bogus" sort of choice, rather than a "does this fit in to our rigorous policies" kind of decision. This would also help avoid the option-overload that comes with #3 on my original example list.
Peter's characterization is correct, however if we had KoPeRs, it's not that hard to expand it to SIG level repos of a less transient nature. The same base work has to be done for either case.
Agreed - it's an almost (if not) identical mechanism, but a very different *policy*.
Peter Jones wrote:
It's very similar, but not quite the same, for a couple of reasons. To wit, Jesse's proposal mostly seems to focus on the repos being somewhat transient - "Bob wants a repo to test something" - whereas I'm discussing a longer-term purpose. Also, his is on a individual level, whereas what I'm discussing would be more at a SIG level. That in some sense may make implementation somewhat easier, by putting a damper on the rate at which they need to be created and destroyed, and also might include some oversight as to whether creating it is really such a good idea - but making it a "is this completely bogus" sort of choice, rather than a "does this fit in to our rigorous policies" kind of decision. This would also help avoid the option-overload that comes with #3 on my original example list.
SIG-level repos would work for stuff like KDE, but what about those packages where a maintainer just wants to provide a new version, but there's no SIG clearly responsible for the package? Many of our packages are maintained by 1 or 2 people, not by a SIG. For example, what about Gnash? I could stick Gnash updates in the KDE SIG repo under your proposal, but I'm not convinced that would be a good place for them. And what about packages which neither clearly map to a SIG by its contents (which is the case for Gnash) nor have a maintainer clearly attached to a SIG (which happens not to be the case for Gnash, but for many other packages, it is, since we do not require membership in any SIG to maintain a package)?
Kevin Kofler
On Thu, 2010-03-04 at 16:19 -0500, Peter Jones wrote:
Obviously this would require some tools work, but isn't it worth considering?
This is essentially serviced by KoPeRs http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
Jesse Keating wrote:
On Thu, 2010-03-04 at 16:19 -0500, Peter Jones wrote:
Obviously this would require some tools work, but isn't it worth considering?
This is essentially serviced by KoPeRs http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
Except this is still vaporware.
Kevin Kofler
Juha Tuomala wrote:
My desktop gui processes leak enough mem that I need to restart couple times a week or system will run out of memory. Today I started with updating the F11 with yum. During the update, I noticed that it's pulling in the kde-4.4.0, scary. Then reboot.
[snip]
KDE SIG, you need to re-think that proposal again.
You mean the KDE stability proposal? As this is F11, i.e. "previous stable", KDE 4.4 would actually not have been pushed to F11 under that proposal.
Kevin Kofler
On Thu, 4 Mar 2010, Kevin Kofler wrote:
You mean the KDE stability proposal? As this is F11, i.e. "previous stable", KDE 4.4 would actually not have been pushed to F11 under that proposal.
How i read it, you would still push *one* feature release in the middle of stable release lifespan, right?
How that's going to solve anything as upstream *intentionally* pushes stuff into it to break things? Even they don't expect you to do what you do.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
Juha Tuomala wrote:
How that's going to solve anything as upstream *intentionally* pushes stuff into it to break things?
Nobody intentionally BREAKS things. Upstream KDE releases are supposed to be backwards compatible, data migration is something which is taken care of. For example, Nepomuk will migrate your data from the Redland (or Sesame2) backend used in older KDE releases to Virtuoso which is now the default as of 4.4. Akonadi also automatically migrates your contacts to the new format.
Kevin Kofler
On Thursday 04 March 2010 15:01:29 Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
You mean the KDE stability proposal? As this is F11, i.e. "previous stable", KDE 4.4 would actually not have been pushed to F11 under that proposal.
How i read it, you would still push *one* feature release in the middle of stable release lifespan, right?
How that's going to solve anything as upstream *intentionally* pushes stuff into it to break things? Even they don't expect you to do what you do.
People who wants stability would be in time of this push to Fn still running Fn-1. Only people who wants new features would be running Fn. There's no sense to have two frozen releases out there! We can just support one for 12 months...
I personally think that update every 6 months breaks much more stuff so letting users to stays as much time with older but still supported releases is what we really want.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
Juha Tuomala wrote:
On Thu, 4 Mar 2010, Kevin Kofler wrote:
You mean the KDE stability proposal? As this is F11, i.e. "previous stable", KDE 4.4 would actually not have been pushed to F11 under that proposal.
How i read it, you would still push *one* feature release in the middle of stable release lifespan, right?
clarification: at *most* one. that means zero is an option too.
-- Rex
Juha Tuomala wrote:
For all those who say that "latest stuff is the
reason why
I use Fedora!!!1", there is rawhide for you.
I have tried this, but that is not possible. Generally, a few weeks after the release of a new fedora, rawhide becomes unusable for a while, even unbootable. My last try went pretty well, lasting from the time fedora 12 was released until about 3 weeks ago, when rawhide just hung and I could not even yum updates or log in. In my experience of a few years of trying Rawhide, it becomes usable again around the time of the release of the alpha release, which is the time I generally switch.
For all those who're claiming users don't want upgrades like KDE 4.4.0: http://lists.fedoraproject.org/pipermail/users/2010-February/367266.html http://lists.fedoraproject.org/pipermail/kde/2010-March/006102.html
Kevin Kofler
On Fri, 5 Mar 2010, Kevin Kofler wrote:
For all those who're claiming users don't want upgrades like KDE 4.4.0: http://lists.fedoraproject.org/pipermail/users/2010-February/367266.html http://lists.fedoraproject.org/pipermail/kde/2010-March/006102.html
Now, lets see you take the leap in logic from those two emails, to the majority of your users without any further research.
-Mike
Mike McGrath wrote:
On Fri, 5 Mar 2010, Kevin Kofler wrote:
For all those who're claiming users don't want upgrades like KDE 4.4.0: http://lists.fedoraproject.org/pipermail/users/2010-February/367266.html http://lists.fedoraproject.org/pipermail/kde/2010-March/006102.html
Now, lets see you take the leap in logic from those two emails, to the majority of your users without any further research.
1. Why shouldn't the burden of proof be on the side which wants to change the status quo? 2. These users are our niche, the others are better served by other distributions. Numbers shouldn't matter. I think blindly charging for popularity is going to kill us. The vast majority of computer users uses Window$ anyway. :-(
Kevin Kofler
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
- Why shouldn't the burden of proof be on the side which wants to change
the status quo?
You seem to be ignoring the fact that there are multiple status quos in Fedora. There is "more stable" (GNOME, Firefox for example) vs. "more rolling" (KDE). I personally think it would be better to have a single (published) status quo across the distribution, so users know what to expect, no matter which desktop, browser, office suite, etc. they choose.
- These users are our niche, the others are better served by other
distributions. Numbers shouldn't matter. I think blindly charging for popularity is going to kill us.
If numbers shouldn't matter, and charging for popularity is bad, why do we need to target your "semi-rolling update" mode?
On Fri, 2010-03-05 at 19:17 +0100, Kevin Kofler wrote:
Mike McGrath wrote:
On Fri, 5 Mar 2010, Kevin Kofler wrote:
For all those who're claiming users don't want upgrades like KDE 4.4.0: http://lists.fedoraproject.org/pipermail/users/2010-February/367266.html http://lists.fedoraproject.org/pipermail/kde/2010-March/006102.html
Now, lets see you take the leap in logic from those two emails, to the majority of your users without any further research.
- Why shouldn't the burden of proof be on the side which wants to change
the status quo? 2. These users are our niche, the others are better served by other distributions. Numbers shouldn't matter. I think blindly charging for popularity is going to kill us. The vast majority of computer users uses Window$ anyway. :-(
Kevin Kofler
What makes your status quo more or less correct that other's status quo? Not every maintainer pushes the way you think they do. There /is/ no status quo out side of "chaos".
A segfaulty version of KDE filelight seems to have been pushed into F13, F12 and (astonishingly) F11. Just filing a bug about that one ...
Rich.
Richard W.M. Jones wrote:
A segfaulty version of KDE filelight seems to have been pushed into F13, F12 and (astonishingly) F11. Just filing a bug about that one ...
Filelight is an application maintained by Neal Becker, not by KDE SIG. This has absolutely nothing to do with KDE SIG's update policy.
Kevin Kofler
-
Adam Williamson -
Andrew Haley -
Bill Nottingham -
Chris Adams -
Emmanuel Seyman -
Jaroslav Reznik -
Jesse Keating -
John5342 -
Juha Tuomala -
Kalev Lember -
Kevin Kofler -
Matthew Woehlke -
Mike McGrath -
Orcan Ogetbil -
Orion Poplawski -
Peter Jones -
Petrus de Calguarium -
Przemek Klosowski -
Rahul Sundaram -
Rajeesh K V -
Rex Dieter -
Richard W.M. Jones -
Ryan Rix -
Sven Lankes -
Thomas Janssen -
Thomas Moschny -
Toshio Kuratomi -
Valent Turkovic