Hi everybody.
Disclaimer: This mail is written from the position of a Fedora community member. Red Hat has nothing to do with this.
I don't want to start yet another rant saying that everything is broken and we'd be better off if we aped Debian. Absolutely not. I don't want to put blame on someone, I want to improve.
Fedora is all about passionate people doing what they want to do in a community of like-minded folks. That's probably the most awesome thing I've seen in my life - a bunch of folks not actually charging money to each other, while providing everybody with fruits of their efforts. It's probably trivial for you, because you've been doing that for years. But for me (as I've been a part only for one year now), it's something almost unimaginable. But reading this list showed me that often the passion goes, at least in my eyes, too far. Instead of constructive criticism, vitriolic scolding and personal insults are to be found. This only makes effort in Fedora fragmented and inconsistent.
One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work.
While it's a simplistic statement with which I don't agree, it points finger at the tradeoff Fedora had to make to become the fastest updated Linux distro in the known universe - to give up much of stability. I sort of like that decision, but I propose to step back and look at the big picture to see if we aren't on the fast side a tad too much. Having a completely new system out every half a year is great, but having a system where various things crash for various reasons pretty much all the time isn't. I don't have a definitive way to fix this, but I have some ideas, and you people out there have better ones. Something like having a solid, tested core that updates half as often as the developer libraries springs into my mind, so I want to know what springs into yours.
The threat for Fedora is that even in the FOSS, there is competition. Distros are competing for users - users that give back, users that report bugs, or users that are or become maintainers and developers. When the overwhelming response to Fedora is "Hey, they've got some neat features, but I need it to work, so that's why I'm using XYZ instead", the user/dev base is going to wither and move elsewhere.
As I said, I don't have the knowledge, mental capacity, or mandate to give the answer to where Fedora is going and where it should be going. I am just worrying that if there is no change in how Fedora is done, it will be harder and harder for the community to thrive, and I wouldn't like that. So, through this e-mail addressed to all the Fedora community, I am seeking support for a movement, both collective and individual, that would improve communication, cooperation and generally the life of Fedora on the most fundamental basis.
To conclude, I don't want this e-mail to be accusing, flaming, or mentoring. It is meant to be concerned, inspiring and accepted with a good, yet scrutinizing mind.
A Fedora contributor, Tomas Radej
On 12/07/2012 12:53 PM, Tomas Radej wrote:
Hi everybody.
Disclaimer: This mail is written from the position of a Fedora community member. Red Hat has nothing to do with this.
I don't want to start yet another rant saying that everything is broken and we'd be better off if we aped Debian. Absolutely not. I don't want to put blame on someone, I want to improve.
Fedora is all about passionate people doing what they want to do in a community of like-minded folks. That's probably the most awesome thing I've seen in my life - a bunch of folks not actually charging money to each other, while providing everybody with fruits of their efforts. It's probably trivial for you, because you've been doing that for years. But for me (as I've been a part only for one year now), it's something almost unimaginable. But reading this list showed me that often the passion goes, at least in my eyes, too far. Instead of constructive criticism, vitriolic scolding and personal insults are to be found. This only makes effort in Fedora fragmented and inconsistent.
One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work.
While it's a simplistic statement with which I don't agree, it points finger at the tradeoff Fedora had to make to become the fastest updated Linux distro in the known universe - to give up much of stability. I sort of like that decision, but I propose to step back and look at the big picture to see if we aren't on the fast side a tad too much. Having a completely new system out every half a year is great, but having a system where various things crash for various reasons pretty much all the time isn't. I don't have a definitive way to fix this, but I have some ideas, and you people out there have better ones. Something like having a solid, tested core that updates half as often as the developer libraries springs into my mind, so I want to know what springs into yours.
The threat for Fedora is that even in the FOSS, there is competition. Distros are competing for users - users that give back, users that report bugs, or users that are or become maintainers and developers. When the overwhelming response to Fedora is "Hey, they've got some neat features, but I need it to work, so that's why I'm using XYZ instead", the user/dev base is going to wither and move elsewhere.
As I said, I don't have the knowledge, mental capacity, or mandate to give the answer to where Fedora is going and where it should be going. I am just worrying that if there is no change in how Fedora is done, it will be harder and harder for the community to thrive, and I wouldn't like that. So, through this e-mail addressed to all the Fedora community, I am seeking support for a movement, both collective and individual, that would improve communication, cooperation and generally the life of Fedora on the most fundamental basis.
To conclude, I don't want this e-mail to be accusing, flaming, or mentoring. It is meant to be concerned, inspiring and accepted with a good, yet scrutinizing mind.
If we want to solve this we need to release an Fedora LTS release for our and the potential other user base that don't have to/want to update every 6 or 12 months.
That's the feed back I have received when I have asked both sysadmins and developers that don't already use Fedora and why they wont use it.
JBG
On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" johannbg@gmail.comwrote:
If we want to solve this we need to release an Fedora LTS release for our
and the potential other user >base that don't have to/want to update every 6 or 12 months.
Completely agree on this one. In my day job we started using Fedora as one of our desktop os. Then support issues and upgrade cycle started giving nightmares to corp IT. They are looking at other avenues now. I really wish there is a LTS release for this awesome distro - Fedora.
On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG sagarun@gmail.com wrote:
On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
If we want to solve this we need to release an Fedora LTS release for our and the potential other user >base that don't have to/want to update every 6 or 12 months.
Completely agree on this one. In my day job we started using Fedora as one of our desktop os. Then support issues and upgrade cycle started giving nightmares to corp IT. They are looking at other avenues now. I really wish there is a LTS release for this awesome distro - Fedora.
Why does there need to be a long-term support for Fedora? Why not just use Red Hat Enterprise Linux?
On 12/08/2012 12:07 AM, M. Edward (Ed) Borasky wrote:
<snip> Why does there need to be a long-term support for Fedora? Why not just use Red Hat Enterprise Linux?
I imagine it boils down to money since Fedora=free and RHEL=$$$. Corporate suits will will weigh cost of Fedora support vs RHEL support and decide accordingly.
Or if money is an issue use Centos.
On Fri, Dec 7, 2012 at 9:35 PM, Clyde E. Kunkel <clydekunkel7734@verizon.net
wrote:
I imagine it boils down to money since Fedora=free and RHEL=$$$.
Corporate suits will will weigh cost >of Fedora support vs RHEL support and decide accordingly.
Or if money is an issue use Centos.
Not really! We are already a customer of RHEL. Money is not the problem. We want our users to use the latest software out there but we also want to reduce the upgrade cycle.
You CANNOT disturb every developer in a company to upgrade his box every 6 months.
On Sunday, December 09, 2012 12:12 AM, Arun SAG wrote:
On Fri, Dec 7, 2012 at 9:35 PM, Clyde E. Kunkel <clydekunkel7734@verizon.net mailto:clydekunkel7734@verizon.net> wrote:
>I imagine it boils down to money since Fedora=free and RHEL=$$$. Corporate suits will will weigh cost >of Fedora support vs RHEL support and decide accordingly. >Or if money is an issue use Centos.
Not really! We are already a customer of RHEL. Money is not the problem. We want our users to use the latest software out there but we also want to reduce the upgrade cycle.
You CANNOT disturb every developer in a company to upgrade his box every 6 months.
You don't have to upgrade every 6 months.
I'm still running Fedora 16 at work because I haven't had time to upgrade.
Am 08.12.2012 17:19, schrieb Mathieu Bridon:
You CANNOT disturb every developer in a company to upgrade his box every 6 months.
You don't have to upgrade every 6 months. I'm still running Fedora 16 at work because I haven't had time to upgrade
finally you have to
yes, you can from time to time make the update 6 months later BUT if you are using F-n also the -n has no longer support after 6 months because this is the release schedule
the upgrade all 6 months is not really a problem mostly it goes smooth
but sometimes there are so large changes and they are too often to make it a hard competition to learn how to work with them besides your normal life and work and they are often in a too few state ______________________________
example:
i loved the idea of systemd long before the first touch i hated the state it had in F15
would F17 have been the first release with systemd in a state between F16-F17 there would not have been so many rant from my side because i am not against changes
i only do not like the feeling my system works against me instead for me, and yes i understand that many things are only become noticed after enough feedback
but there is a difference between "leading edge" and "bloody edge"
On Sat, Dec 08, 2012 at 08:12:24 -0800, Arun SAG sagarun@gmail.com wrote:
Not really! We are already a customer of RHEL. Money is not the problem. We want our users to use the latest software out there but we also want to reduce the upgrade cycle.
You CANNOT disturb every developer in a company to upgrade his box every 6 months.
Those are somewhat conflicting requirements. Maybe RHEL plus a local repo for packages you need more up to date than what is provided for in RHEL would work for you.
Am 08.12.2012 17:25, schrieb Bruno Wolff III:
On Sat, Dec 08, 2012 at 08:12:24 -0800, Arun SAG sagarun@gmail.com wrote:
Not really! We are already a customer of RHEL. Money is not the problem. We want our users to use the latest software out there but we also want to reduce the upgrade cycle.
You CANNOT disturb every developer in a company to upgrade his box every 6 months.
Those are somewhat conflicting requirements. Maybe RHEL plus a local repo for packages you need more up to date than what is provided for in RHEL would work for you.
this does not work
a few years after RHEL release you will be unable for many "local builds" because build requirements does not fit and it is hardly possible to fullfil them and update a lot of depending libraries also with local builds without collide/break with the rest of the distribution
On 12/08/2012 04:12 PM, Arun SAG wrote:
Not really! We are already a customer of RHEL. Money is not the problem. We want our users to use the latest software out there but we also want to reduce the upgrade cycle.
I don't understand what you're saying. If you want your users to use latest software out there they're going to have to upgrade regularly. Otherwise, it's not going to be the latest software. How in the world could it possibly be any different?
Andrew.
On 12/08/2012 06:07 AM, M. Edward (Ed) Borasky wrote:
On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG sagarun@gmail.com wrote:
On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
If we want to solve this we need to release an Fedora LTS release for our and the potential other user >base that don't have to/want to update every 6 or 12 months.
Completely agree on this one. In my day job we started using Fedora as one of our desktop os. Then support issues and upgrade cycle started giving nightmares to corp IT. They are looking at other avenues now. I really wish there is a LTS release for this awesome distro - Fedora.
Why does there need to be a long-term support for Fedora?
My primary problem with Fedora isn't "lack of stability", but lack of API/ABI and UI-stability/persistence/sustainability between upgrades.
In other words, I can cope with the number of crashes upgrades typically come along with, but the number "UI-changes" is what makes Fedora difficult to use for me.
Why not just use Red Hat Enterprise Linux?
My view: RHEL is not an alternative to Fedora. CentOS would be a candidate alternative to Fedora, however due to the nature of its upstream and its upstream target audience (servers) it lacks a lot to be functionally "on par" with Fedora.
That said, if I was managing a larger network, I'd likely choose CentOS as base OS and harvest Fedora to setup a custom "add-on" repo.
Ralf
This IS a rant. And this includes a few analogies. Some good, some bad.
This is one of the reasons why I chose to run for board.
Nobody really knows where Fedora is going. It's like a too many chefs problem.
Sometimes Fedora just feels like a bunch of people/SIGs working independent of each other (Red Hat included) that eventually come together to make the entire distro.
There needs to be a more concerted to have a direction. There needs to be more communication with end users and what they want from Fedora.
For example, the same thing happened with Gnome 3 upstream where a lot of developers left the project due to a lack of a real vision or direction.
"Let's just include the latest greatest things that are cool in the Linux world." (FIRST on FEATURES) is part of the problem.
"Let's make it look like Ubuntu because Ubuntu is popular" is another philosophy that I have seen and I have a problem with.
In addition, LTS won't solve this problem. It goes against everything Fedora stands for. A really bad analogy and half joking here: LTS should just be renamed "Slackware". If you get the analogy kudos to you.
In my opinion the vision needs to be changed. It feels like Fedora has turned into Rawhide more than Fedora with 17 and even more so with 18.
If there was more testing done with Rawhide then I wouldn't feel like the 6 month release cycle may be a bit too aggressive right now.
I mean the proof is in the pudding. Spherical Cow is almost 3 months late.
Going forward, I would like to look at what the real vision and direction of Fedora should be.
In my opinion it should be a distribution that offers the latest software, but at the same time keeping stability and compatibility a #1 priority.
At the end of the day the people that make a distro popular are the users, developers and sysadmins.
Sysadmins want things to just work as they have been for the last 15-20 years with some minor improvements that don't require them to go back and relearn everything. They don't have time for it.
Just my 2 cents.
Dan
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Ralf Corsepius Sent: Friday, December 07, 2012 9:51 PM To: devel@lists.fedoraproject.org Subject: Re: Where are we going? (Not a rant)
On 12/08/2012 06:07 AM, M. Edward (Ed) Borasky wrote:
On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG sagarun@gmail.com wrote:
On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
If we want to solve this we need to release an Fedora LTS release for our and the potential other user >base that don't have to/want to update every 6 or 12 months.
Completely agree on this one. In my day job we started using Fedora as one of our desktop os. Then support issues and upgrade cycle started giving nightmares to corp IT. They are looking at other avenues now. I really wish there is a LTS release for this awesome distro - Fedora.
Why does there need to be a long-term support for Fedora?
My primary problem with Fedora isn't "lack of stability", but lack of API/ABI and UI-stability/persistence/sustainability between upgrades.
In other words, I can cope with the number of crashes upgrades typically come along with, but the number "UI-changes" is what makes Fedora difficult to use for me.
Why not just use Red Hat Enterprise Linux?
My view: RHEL is not an alternative to Fedora. CentOS would be a candidate alternative to Fedora, however due to the nature of its upstream and its upstream target audience (servers) it lacks a lot to be functionally "on par" with Fedora.
That said, if I was managing a larger network, I'd likely choose CentOS as base OS and harvest Fedora to setup a custom "add-on" repo.
Ralf
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Dec 8, 2012 at 7:12 AM, Dan Mashal dan.mashal@gmail.com wrote:
This IS a rant. And this includes a few analogies. Some good, some bad.
This is one of the reasons why I chose to run for board.
Nobody really knows where Fedora is going. It's like a too many chefs problem.
We might not have enough chefs. If we pick a handful of top chefs we create a recipe for far less innovation. If you have 20 minutes you might enjoy thinking about what Charles Leadbeater has to say about open innovation and whether/how we might apply these idea to our organization.
http://www.ted.com/talks/charles_leadbeater_on_innovation.html
John
Le samedi 08 décembre 2012 à 05:12 -0800, Dan Mashal a écrit :
This IS a rant. And this includes a few analogies. Some good, some bad.
This is one of the reasons why I chose to run for board.
Nobody really knows where Fedora is going. It's like a too many chefs problem.
Sometimes Fedora just feels like a bunch of people/SIGs working independent of each other (Red Hat included) that eventually come together to make the entire distro.
That's kinda how free software work, in fact, individual group of people producing a small part of the system.
There needs to be a more concerted to have a direction. There needs to be more communication with end users and what they want from Fedora.
For example, the same thing happened with Gnome 3 upstream where a lot of developers left the project due to a lack of a real vision or direction.
That's not really what seems to be seen with the graph at ohloh : http://www.ohloh.net/p/gnome/contributors/summary
on 5 years, the number of contributers seems quite constant, and I think the few people that left could be attributed to others external factors such as : * canonical focusing on unity, * nokia's fate and the move on QT for meegoo ( http://www.vuntz.net/journal/post/2009/07/04/Nokia-GNOME-Mobile ) * sun/oracle merger and the various internal changes this could have created, * problem at opensimus ( http://www.murrayc.com/blog/permalink/2012/06/22/openismus-status/, http://www.murrayc.com/blog/permalink/2012/11/08/gtkmm-maintainership/ ), and similar likely due to the financial crisis or IT cost reductions
Companies are where you find lots of contributions, not end users.
In fact, I never heard anyone complaining about "kde is dying" while the numbers are much more worrisome : http://www.ohloh.net/p/kde/contributors/summary
Maybe that's caused by some cleaning of their svn, or maybe that's just nokia's problem ( and the huge layoff that followed ).
I would also add that if the switch to gnome 3 made enough people leave the project, they would have gone to mate, and afaik, no one coding on mate has a @gnome.org email. In fact, mate do take a lot of commits from gnome : https://github.com/mate-desktop/mate-settings-daemon/commit/6e61d207a2088479... https://github.com/mate-desktop/mate-settings-daemon/commit/f86fbc0aa5809b6a... https://github.com/mate-desktop/mate-settings-daemon/commit/75e8a3f7a9322bba... https://github.com/mate-desktop/mate-settings-daemon/commit/6e182dc5cdb3451a... ( ie, 4 out of the 5 commits merge on 06/12/2012 come from gnome )
People told "users would migrate to xfce", yet it didn't translate into more contributors for the project : http://www.ohloh.net/p/xfce/contributors/summary
( and you can check also for lxde, and others ).
So your assertion of "lots of developers left because of the lack of vision" is IMHO wrong.
And I would not say that GNOME do not have a vision, quite the contrary, they do have a idea of what they want to achieve ( at least, Jon McCann, has, cf http://derstandard.at/1343744803999/McCann-More-optimistic-about-GNOME-than-... ), and that's something that bother part of the user base, because they do not share the vision. Google for "Design Principles for the Next Generation Desktop" to see a talk about that, or look at the various GUADEC talk and proposal in the past.
"Let's just include the latest greatest things that are cool in the Linux world." (FIRST on FEATURES) is part of the problem.
"Let's make it look like Ubuntu because Ubuntu is popular" is another philosophy that I have seen and I have a problem with.
In addition, LTS won't solve this problem. It goes against everything Fedora stands for.
So "first on feature" is a problem, but that's what Fedora stand for. Yet, LTS would be bad because it goes against what Fedora stand for.
I fail to follow your line of reasoning here as it seems to contradict itself, sorry.
A really bad analogy and half joking here: LTS should just be renamed "Slackware". If you get the analogy kudos to you.
In my opinion the vision needs to be changed. It feels like Fedora has turned into Rawhide more than Fedora with 17 and even more so with 18.
You mean like people who are pushing features (https://fedoraproject.org/wiki/Features/MATE-Desktop ) directly on all stable releases ( https://admin.fedoraproject.org/updates/mate-desktop ), despites being frowned upon by the policy : https://fedoraproject.org/wiki/Updates_Policy#All_other_updates , who was part of the vision that the board proposed : http://fedoraproject.org/wiki/Stable_release_updates_vision ) ?
If you want to avoid Fedora 17 turning into rawhide ( ie, a rolling release where is pushed latest version of packages ), I would propose to start by following your own ideas, and help others to follow the rules about it, instead of asking for others to do one thing, and yet do another one yourself.
If there was more testing done with Rawhide then I wouldn't feel like the 6 month release cycle may be a bit too aggressive right now.
I mean the proof is in the pudding. Spherical Cow is almost 3 months late.
On https://fedoraproject.org/wiki/Releases/18/Schedule?rd=Releases/18 , I see 2 months and 2 days, hardly 3 months late. Not to mention that IMHO, part of the problem is due to christmas holidays, and thanksgiving. ( and that would remove 3 weeks out of the 8 weeks late ). So that's more 5 weeks, instead of 12 ( 3x4 ).
Anyway, your concrete proposal is ( cause this has been discussed to death already, so let's go forward and fix the issue if this is important ) ?
in fact speaking of more testing in rawhide, do you run rawhide ? If not, maybe that's something that is part of the problem, and the first step to a solution. IE, someone should volunteer, and get enough feedback on why people in the fedora community do not run rawhide. Once the problems are identified ( even roughly ), then the next step to correct them could be found.
If the issue "people tell me to not do it", then we should change the message. If the issue is "I did it but this $class_of_bug made me lose months of work", then we should find a way to prevent $class_of_bug, and make it know. And so on.
But just saying "more tests should be done on rawhide" doesn't make them happen. You cannot force people to run rawhide.
Going forward, I would like to look at what the real vision and direction of Fedora should be.
In my opinion it should be a distribution that offers the latest software, but at the same time keeping stability and compatibility a #1 priority.
Fedora community do not develop most softwares we ship, that's usually the job of upstream communities ( such as gnome, xorg, gcc ). So you should engage them into buying your vision about stability and see what they need, and help them.
For example, I am sure the people who work on http://ispras.linuxbase.org/index.php/ABI_compliance_checker would love to have their tools integrated into upstream projects, so warnings can be emitted when ABI is changed, and pushing that as best practice ( like pushing fuzzing or valgrind memory check ) would be a good step into more compatibility.
Or maybe add this into autoQA ( and fix https://fedorahosted.org/autoqa/ticket/190 ).
At the end of the day the people that make a distro popular are the users, developers and sysadmins.
Sysadmins want things to just work as they have been for the last 15-20 years with some minor improvements that don't require them to go back and relearn everything. They don't have time for it.
I do not know for you, but as a sysadmin, I do not care having to learn new things. For example, I am looking forward cleaning some cruft with systemd migration. I do not expect to live in a bubble unaffected by the fact that the rest of the world is moving. 15/20 years ago, we didn't have cloud/virtualisation, BYOD trend, hyper connected work force, etc.
So sysadmins and IT has to adapt daily. And changes into systems are just part of the job. People are paid because they are able to adapt.
On Sat, 2012-12-08 at 17:31 +0100, Michael Scherer wrote:
In my opinion the vision needs to be changed. It feels like Fedora has turned into Rawhide more than Fedora with 17 and even more so with 18.
You mean like people who are pushing features (https://fedoraproject.org/wiki/Features/MATE-Desktop ) directly on all stable releases ( https://admin.fedoraproject.org/updates/mate-desktop ), despites being frowned upon by the policy : https://fedoraproject.org/wiki/Updates_Policy#All_other_updates , who was part of the vision that the board proposed : http://fedoraproject.org/wiki/Stable_release_updates_vision ) ?
In general, adding packages in an update is actually a fairly safe thing to do, as it's very unlikely to disturb any existing setups unless some of those packages somehow provide stuff existing packages might depend on. You have to explicitly install the new packages in order to be in any way 'affected' by them. I thought the updates policy mentioned this, but I can't find it any more.
On Sat, Dec 08, 2012 at 09:32:01AM -0800, Adam Williamson wrote:
In general, adding packages in an update is actually a fairly safe thing to do, as it's very unlikely to disturb any existing setups unless some of those packages somehow provide stuff existing packages might depend on. You have to explicitly install the new packages in order to be in any way 'affected' by them. I thought the updates policy mentioned this, but I can't find it any more.
Seems like yet another reason to separate the leaf features from major-update features.
On 12/08/2012 12:32 PM, Adam Williamson wrote:
In general, adding packages in an update is actually a fairly safe thing to do, as it's very unlikely to disturb any existing setups unless some of those packages somehow provide stuff existing packages might depend on. You have to explicitly install the new packages in order to be in any way 'affected' by them. I thought the updates policy mentioned this, but I can't find it any more.
You can propose that as a revision for FESCo
Rahul
Le samedi 08 décembre 2012 à 09:32 -0800, Adam Williamson a écrit :
On Sat, 2012-12-08 at 17:31 +0100, Michael Scherer wrote:
In my opinion the vision needs to be changed. It feels like Fedora has turned into Rawhide more than Fedora with 17 and even more so with 18.
You mean like people who are pushing features (https://fedoraproject.org/wiki/Features/MATE-Desktop ) directly on all stable releases ( https://admin.fedoraproject.org/updates/mate-desktop ), despites being frowned upon by the policy : https://fedoraproject.org/wiki/Updates_Policy#All_other_updates , who was part of the vision that the board proposed : http://fedoraproject.org/wiki/Stable_release_updates_vision ) ?
In general, adding packages in an update is actually a fairly safe thing to do, as it's very unlikely to disturb any existing setups unless some of those packages somehow provide stuff existing packages might depend on. You have to explicitly install the new packages in order to be in any way 'affected' by them. I thought the updates policy mentioned this, but I can't find it any more.
While I have no problem with pushing new packages to stable release, in this case, my point is there is a version upgrade from 1.4 to 1.5 ( but yes, i didn't clearly epxressed myself on this part ). Just take for example mate-desktop :
https://admin.fedoraproject.org/updates/mate-desktop
Mate 1.4 is the stable release, 1.5 is the development release, following the same version numbering as GNOME. Even if that's not explicitly said, there is no 1.5 on the roadmap ( http://wiki.mate-desktop.org/roadmap ), and people keep talking of the 1.6 as being the next stable.
For example, 1.5 have been converted from mate-conf to gsettings, from corba to dbus, etc. And there is a few deprecated stuff that should disappear sooner or later.
So yes, that's pushing a development version on stable release, ie, using stable release as rawhide.
Now, if that's good or not is not what I am discussing, it is the contradiction between saying "we should not do that", and doing it.
Please don't speak about things you don't understand.
MATE 1.5 is more stable than 1.4 and was pushed for a reason.
Dan
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Michael Scherer Sent: Saturday, December 08, 2012 10:42 AM To: devel@lists.fedoraproject.org Subject: Re: Where are we going? (Not a rant)
Le samedi 08 décembre 2012 à 09:32 -0800, Adam Williamson a écrit :
On Sat, 2012-12-08 at 17:31 +0100, Michael Scherer wrote:
In my opinion the vision needs to be changed. It feels like Fedora has turned into Rawhide more than Fedora with 17 and even more so with 18.
You mean like people who are pushing features (https://fedoraproject.org/wiki/Features/MATE-Desktop ) directly on all stable releases ( https://admin.fedoraproject.org/updates/mate-desktop ), despites being frowned upon by the policy : https://fedoraproject.org/wiki/Updates_Policy#All_other_updates , who was part of the vision that the board proposed : http://fedoraproject.org/wiki/Stable_release_updates_vision ) ?
In general, adding packages in an update is actually a fairly safe thing to do, as it's very unlikely to disturb any existing setups unless some of those packages somehow provide stuff existing packages might depend on. You have to explicitly install the new packages in order to be in any way 'affected' by them. I thought the updates policy mentioned this, but I can't find it any more.
While I have no problem with pushing new packages to stable release, in this case, my point is there is a version upgrade from 1.4 to 1.5 ( but yes, i didn't clearly epxressed myself on this part ). Just take for example mate-desktop :
https://admin.fedoraproject.org/updates/mate-desktop
Mate 1.4 is the stable release, 1.5 is the development release, following the same version numbering as GNOME. Even if that's not explicitly said, there is no 1.5 on the roadmap ( http://wiki.mate-desktop.org/roadmap ), and people keep talking of the 1.6 as being the next stable.
For example, 1.5 have been converted from mate-conf to gsettings, from corba to dbus, etc. And there is a few deprecated stuff that should disappear sooner or later.
So yes, that's pushing a development version on stable release, ie, using stable release as rawhide.
Now, if that's good or not is not what I am discussing, it is the contradiction between saying "we should not do that", and doing it.
-- Michael Scherer
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, 08 Dec 2012 17:31:54 +0100 Michael Scherer misc@zarb.org wrote:
...snip...
in fact speaking of more testing in rawhide, do you run rawhide ? If not, maybe that's something that is part of the problem, and the first step to a solution. IE, someone should volunteer, and get enough feedback on why people in the fedora community do not run rawhide. Once the problems are identified ( even roughly ), then the next step to correct them could be found.
If the issue "people tell me to not do it", then we should change the message. If the issue is "I did it but this $class_of_bug made me lose months of work", then we should find a way to prevent $class_of_bug, and make it know. And so on.
But just saying "more tests should be done on rawhide" doesn't make them happen. You cannot force people to run rawhide.
...snip...
Just to highlight this... I intend to switch my laptop to rawhide and run it and try and gather a like minded group of people to fix things as they break faster and work on making rawhide more day to day consumable. I'll likely do this switch over the holidays.
I'd like to continue to use this list for this effort (with the idea that increasing signal here would be welcome).
Some random ideas:
Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.
Help improve autoqa efforts around rawhide and see if we can prevent broken packages from even promoting into the collection.
Note directly rawhide related discussion on this list with a [rawhide] so people can easily pick out workarounds and discussions on day to day rawhide bugs.
Try to give maintainers feedback when they push something to rawhide that doesn't work at all, and help untag builds identified that do this before they go out in the next compose.
Other ideas welcome.
kevin
Kevin,
This is great and is exactly what I was talking about.
Michael,
For the record, yes I run rawhide.
I have Fedora 14,16,17,18 and 19 running here.
Dan
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Kevin Fenzi Sent: Saturday, December 08, 2012 10:18 AM To: devel@lists.fedoraproject.org Subject: [rawhide] (was Re: Where are we going? (Not a rant))
On Sat, 08 Dec 2012 17:31:54 +0100 Michael Scherer misc@zarb.org wrote:
...snip...
in fact speaking of more testing in rawhide, do you run rawhide ? If not, maybe that's something that is part of the problem, and the first step to a solution. IE, someone should volunteer, and get enough feedback on why people in the fedora community do not run rawhide. Once the problems are identified ( even roughly ), then the next step to correct them could be found.
If the issue "people tell me to not do it", then we should change the message. If the issue is "I did it but this $class_of_bug made me lose months of work", then we should find a way to prevent $class_of_bug, and make it know. And so on.
But just saying "more tests should be done on rawhide" doesn't make them happen. You cannot force people to run rawhide.
...snip...
Just to highlight this... I intend to switch my laptop to rawhide and run it and try and gather a like minded group of people to fix things as they break faster and work on making rawhide more day to day consumable. I'll likely do this switch over the holidays.
I'd like to continue to use this list for this effort (with the idea that increasing signal here would be welcome).
Some random ideas:
Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.
Help improve autoqa efforts around rawhide and see if we can prevent broken packages from even promoting into the collection.
Note directly rawhide related discussion on this list with a [rawhide] so people can easily pick out workarounds and discussions on day to day rawhide bugs.
Try to give maintainers feedback when they push something to rawhide that doesn't work at all, and help untag builds identified that do this before they go out in the next compose.
Other ideas welcome.
kevin
Hey Dan,
In all the given distributions in your post, is there one that you prefer more than the others?
Richard On Dec 8, 2012 1:25 PM, "Dan Mashal" dan.mashal@gmail.com wrote:
Kevin,
This is great and is exactly what I was talking about.
Michael,
For the record, yes I run rawhide.
I have Fedora 14,16,17,18 and 19 running here.
Dan
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Kevin Fenzi Sent: Saturday, December 08, 2012 10:18 AM To: devel@lists.fedoraproject.org Subject: [rawhide] (was Re: Where are we going? (Not a rant))
On Sat, 08 Dec 2012 17:31:54 +0100 Michael Scherer misc@zarb.org wrote:
...snip...
in fact speaking of more testing in rawhide, do you run rawhide ? If not, maybe that's something that is part of the problem, and the first step to a solution. IE, someone should volunteer, and get enough feedback on why people in the fedora community do not run rawhide. Once the problems are identified ( even roughly ), then the next step to correct them could be found.
If the issue "people tell me to not do it", then we should change the message. If the issue is "I did it but this $class_of_bug made me lose months of work", then we should find a way to prevent $class_of_bug, and make it know. And so on.
But just saying "more tests should be done on rawhide" doesn't make them happen. You cannot force people to run rawhide.
...snip...
Just to highlight this... I intend to switch my laptop to rawhide and run it and try and gather a like minded group of people to fix things as they break faster and work on making rawhide more day to day consumable. I'll likely do this switch over the holidays.
I'd like to continue to use this list for this effort (with the idea that increasing signal here would be welcome).
Some random ideas:
Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.
Help improve autoqa efforts around rawhide and see if we can prevent broken packages from even promoting into the collection.
Note directly rawhide related discussion on this list with a [rawhide] so people can easily pick out workarounds and discussions on day to day rawhide bugs.
Try to give maintainers feedback when they push something to rawhide that doesn't work at all, and help untag builds identified that do this before they go out in the next compose.
Other ideas welcome.
kevin
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Hi Richard,
14 is my favorite.
However, it's so out of date that usually the VM is powered off. I usually power it on these days for nostalgic purposes.
Most of the time these days I'm running 18 for doing QA and packaging work.
Thanks,
Dan
From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Richard Vickery Sent: Sunday, December 09, 2012 11:10 AM To: Development discussions related to Fedora Subject: RE: [rawhide] (was Re: Where are we going? (Not a rant))
Hey Dan,
In all the given distributions in your post, is there one that you prefer more than the others?
Richard
On Dec 8, 2012 1:25 PM, "Dan Mashal" <dan.mashal@gmail.com mailto:dan.mashal@gmail.com > wrote:
Kevin,
This is great and is exactly what I was talking about.
Michael,
For the record, yes I run rawhide.
I have Fedora 14,16,17,18 and 19 running here.
Dan
-----Original Message----- From: devel-bounces@lists.fedoraproject.org mailto:devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org mailto:devel-bounces@lists.fedoraproject.org ] On Behalf Of Kevin Fenzi Sent: Saturday, December 08, 2012 10:18 AM To: devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org Subject: [rawhide] (was Re: Where are we going? (Not a rant))
On Sat, 08 Dec 2012 17:31:54 +0100 Michael Scherer <misc@zarb.org mailto:misc@zarb.org > wrote:
...snip...
in fact speaking of more testing in rawhide, do you run rawhide ? If not, maybe that's something that is part of the problem, and the first step to a solution. IE, someone should volunteer, and get enough feedback on why people in the fedora community do not run rawhide. Once the problems are identified ( even roughly ), then the next step to correct them could be found.
If the issue "people tell me to not do it", then we should change the message. If the issue is "I did it but this $class_of_bug made me lose months of work", then we should find a way to prevent $class_of_bug, and make it know. And so on.
But just saying "more tests should be done on rawhide" doesn't make them happen. You cannot force people to run rawhide.
...snip...
Just to highlight this... I intend to switch my laptop to rawhide and run it and try and gather a like minded group of people to fix things as they break faster and work on making rawhide more day to day consumable. I'll likely do this switch over the holidays.
I'd like to continue to use this list for this effort (with the idea that increasing signal here would be welcome).
Some random ideas:
Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.
Help improve autoqa efforts around rawhide and see if we can prevent broken packages from even promoting into the collection.
Note directly rawhide related discussion on this list with a [rawhide] so people can easily pick out workarounds and discussions on day to day rawhide bugs.
Try to give maintainers feedback when they push something to rawhide that doesn't work at all, and help untag builds identified that do this before they go out in the next compose.
Other ideas welcome.
kevin
-- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Dec 8, 2012 at 10:18 AM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 08 Dec 2012 17:31:54 +0100 Michael Scherer misc@zarb.org wrote:
Just to highlight this... I intend to switch my laptop to rawhide and run it and try and gather a like minded group of people to fix things as they break faster and work on making rawhide more day to day consumable. I'll likely do this switch over the holidays.
I'd like to continue to use this list for this effort (with the idea that increasing signal here would be welcome).
Some random ideas:
Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs to get added to that and we have a pool of people watching it who can fix or nag maintainers to fix such issues as a higher priority. We would need to come up with some critera for acceptance there.
Help improve autoqa efforts around rawhide and see if we can prevent broken packages from even promoting into the collection.
Note directly rawhide related discussion on this list with a [rawhide] so people can easily pick out workarounds and discussions on day to day rawhide bugs.
Try to give maintainers feedback when they push something to rawhide that doesn't work at all, and help untag builds identified that do this before they go out in the next compose.
Other ideas welcome.
kevin
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
There's no way I can run my laptop on Rawhide - it's dual-booted with Windows 8 Pro and Fedora 18. But I do have an ancient crash-and-burn workstation I can run Rawhide on. It's currently dual-booted Fedora 18 and Linux Mint 14, but I rarely run the Mint part and I could easily convert that partition to Rawhide or even blow away Fedora 18 and Mint in favor of Rawhide.
Le dimanche 09 décembre 2012 à 15:18 -0800, M. Edward (Ed) Borasky a écrit :
There's no way I can run my laptop on Rawhide - it's dual-booted with Windows 8 Pro and Fedora 18. But I do have an ancient crash-and-burn workstation I can run Rawhide on. It's currently dual-booted Fedora 18 and Linux Mint 14, but I rarely run the Mint part and I could easily convert that partition to Rawhide or even blow away Fedora 18 and Mint in favor of Rawhide.
What about doing a triple boot, if you share swap and /home, you can get enough space to install a 3rd distro, no ?
On Sun, Dec 9, 2012 at 4:16 PM, Michael Scherer misc@zarb.org wrote:
Le dimanche 09 décembre 2012 à 15:18 -0800, M. Edward (Ed) Borasky a écrit :
There's no way I can run my laptop on Rawhide - it's dual-booted with Windows 8 Pro and Fedora 18. But I do have an ancient crash-and-burn workstation I can run Rawhide on. It's currently dual-booted Fedora 18 and Linux Mint 14, but I rarely run the Mint part and I could easily convert that partition to Rawhide or even blow away Fedora 18 and Mint in favor of Rawhide.
What about doing a triple boot, if you share swap and /home, you can get enough space to install a 3rd distro, no ?
It's not worth the effort - the machine is the first dual-core Athlon ever built, the USB ports are either dead or 1.1, the NVidia card is mucked up and it only has 4 GB of RAM. I do most of my testing in VMs on the 8 GB laptop under virt-manager on Fedora or VirtualBox and VMware Workstation on Windows. I've also got the Client Hyper-V feature of Windows 8 Pro on the laptop but it needs a wired network to function coherently. I'll probably haul the workstation down to FreeGeek and just make the laptop my workstation. Rawhide's fine in a VM. ;-)
On Sun, Dec 9, 2012 at 6:21 PM, M. Edward (Ed) Borasky znmeb@znmeb.net wrote:
On Sun, Dec 9, 2012 at 4:16 PM, Michael Scherer misc@zarb.org wrote:
Le dimanche 09 décembre 2012 à 15:18 -0800, M. Edward (Ed) Borasky a écrit :
There's no way I can run my laptop on Rawhide - it's dual-booted with Windows 8 Pro and Fedora 18. But I do have an ancient crash-and-burn workstation I can run Rawhide on. It's currently dual-booted Fedora 18 and Linux Mint 14, but I rarely run the Mint part and I could easily convert that partition to Rawhide or even blow away Fedora 18 and Mint in favor of Rawhide.
What about doing a triple boot, if you share swap and /home, you can get enough space to install a 3rd distro, no ?
It's not worth the effort - the machine is the first dual-core Athlon ever built, the USB ports are either dead or 1.1, the NVidia card is mucked up and it only has 4 GB of RAM. I do most of my testing in VMs on the 8 GB laptop under virt-manager on Fedora or VirtualBox and VMware Workstation on Windows. I've also got the Client Hyper-V feature of Windows 8 Pro on the laptop but it needs a wired network to function coherently. I'll probably haul the workstation down to FreeGeek and just make the laptop my workstation. Rawhide's fine in a VM. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs?
Update - I have said ancient creaky workstation dual-booted Fedora 18 Beta and Rawhide and the Rawhide partition is now "stable". There were two show-stoppers on the Rawhide piece - some kind of bizarre X.org / nouveau issue that was locking the machine up when I opened Firefox, and a missing dependency for LibreOffice. Those have gone away and I can now use the machine in Rawhide.
I'll probably switch to Firefox beta and put in the Chrome beta as well, since I spend a lot of time in the browser. Might as well live on the edge. ;-)
On 12/08/2012 05:31 PM, Michael Scherer wrote:
Le samedi 08 décembre 2012 à 05:12 -0800, Dan Mashal a écrit :
In fact, I never heard anyone complaining about "kde is dying" while the numbers are much more worrisome : http://www.ohloh.net/p/kde/contributors/summary
Maybe that's caused by some cleaning of their svn, or maybe that's just nokia's problem ( and the huge layoff that followed ).
I would also add that if the switch to gnome 3 made enough people leave the project,
Which project are you referring to?
Fedora? It's thanks to Linux offering alternatives to Gnome, which allows users to switch to a different GUI.
they would have gone to mate, and afaik, no one coding on mate has a @gnome.org email.
Well, this doesn't surprise me at all for several reasons, primarily because many Gnome coders are employed for coding on Gnome, the Gnome coders are convinced about their work and because it's the Gnome 3 dissatisfied users who are switching their GUI (user != coder).
People told "users would migrate to xfce", yet it didn't translate into more contributors for the project : http://www.ohloh.net/p/xfce/contributors/summary
c.f. above. (user != coder).
"Let's make it look like Ubuntu because Ubuntu is popular" is another philosophy that I have seen and I have a problem with.
In addition, LTS won't solve this problem. It goes against everything Fedora stands for.
So "first on feature" is a problem, but that's what Fedora stand for. Yet, LTS would be bad because it goes against what Fedora stand for.
IMO, no. LTS can also mean to improve parallel installations (ship forward-compat packages).
An alterative to LTS could be to improve upgrades (Make them easier/seamless) and encourage backward-compat packages. For instance, I never understood why "last RHEL"-compatibility had never been an objective for Fedora. Though this certainly will not always be possible, achieving this is likely possible for a larger number of packages.
Ralf
Le samedi 08 décembre 2012 à 19:31 +0100, Ralf Corsepius a écrit :
On 12/08/2012 05:31 PM, Michael Scherer wrote:
Le samedi 08 décembre 2012 à 05:12 -0800, Dan Mashal a écrit :
In fact, I never heard anyone complaining about "kde is dying" while the numbers are much more worrisome : http://www.ohloh.net/p/kde/contributors/summary
Maybe that's caused by some cleaning of their svn, or maybe that's just nokia's problem ( and the huge layoff that followed ).
I would also add that if the switch to gnome 3 made enough people leave the project,
Which project are you referring to?
I refer to GNOME, as "the project" from "For example, the same thing happened with Gnome 3 upstream where a lot of developers left the project due to a lack of a real vision or direction."
It was obvious in my head, but in my head only :/
"Let's make it look like Ubuntu because Ubuntu is popular" is another philosophy that I have seen and I have a problem with.
In addition, LTS won't solve this problem. It goes against everything Fedora stands for.
So "first on feature" is a problem, but that's what Fedora stand for. Yet, LTS would be bad because it goes against what Fedora stand for.
IMO, no. LTS can also mean to improve parallel installations (ship forward-compat packages).
An alternative to LTS could be to improve upgrades (Make them easier/seamless) and encourage backward-compat packages. For instance, I never understood why "last RHEL"-compatibility had never been an objective for Fedora. Though this certainly will not always be possible, achieving this is likely possible for a larger number of packages.
There is a chicken and egg problem. To be sure we are still compatible, we need people to test that. But no one will test if we are not compatible.
And I do not deny this would surely be helpful but it can quickly become complex as hell.
If I take for example openshift origin, running on RHEL 6, being able to run it unmodified requires to keep older version of rails ( as the upgrade to rails 3.2 broke some code ), older ruby ( as I am not sure that all gems support ruby 1.9, but that's just a speculation and i may be wrong ), and surely a few gems. This also requires keeping some compatibility layer for sysctl knobs, cgroups, etc.
And then we are back on the software collection discussion, among others. And this would also conflict with the idea of not diverging too much from upstream, if upstream do not care about compatibility.
This would also mean that lots of thing would break every 2/3 years for each new RHEL version, and that we let Red hat decide of the compatibility of Fedora, which is undesirable IMHO.
Another problematic area would be the kernel. Do we want to have RHEL compatibility on this ? Or Xorg ?
On Sat, Dec 08, 2012 at 05:31:54PM +0100, Michael Scherer wrote:
I would also add that if the switch to gnome 3 made enough people leave the project, they would have gone to mate, and afaik, no one coding on mate has a @gnome.org email. In fact, mate do take a lot of commits from gnome :
Some additional information in case anyone cares: I heard that there are 5 or so MATE developers. Two of which have taken over a GNOME module (gnome-main-menu) as of last week or so. Meaning: they have maintainer (which is different from just developer status). As a result, these two maintainers have GNOME git accounts plus they can approve git accounts for other people. I've explicitly said to them that they it is fine to do so (grant git accounts) for all other MATE developers (obviously not limited to MATE).
X vs Y vs Z (e.g. GNOME/MATE/XFCE) discussions are boring. :P
MATE IS growing. And MATE developers are starting to contribute to Gnome. :)
Dan
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Olav Vitters Sent: Sunday, December 09, 2012 5:42 AM To: devel@lists.fedoraproject.org Subject: Re: Where are we going? (Not a rant)
On Sat, Dec 08, 2012 at 05:31:54PM +0100, Michael Scherer wrote:
I would also add that if the switch to gnome 3 made enough people leave the project, they would have gone to mate, and afaik, no one coding on mate has a @gnome.org email. In fact, mate do take a lot of commits from gnome :
Some additional information in case anyone cares: I heard that there are 5 or so MATE developers. Two of which have taken over a GNOME module (gnome-main-menu) as of last week or so. Meaning: they have maintainer (which is different from just developer status). As a result, these two maintainers have GNOME git accounts plus they can approve git accounts for other people. I've explicitly said to them that they it is fine to do so (grant git accounts) for all other MATE developers (obviously not limited to MATE).
X vs Y vs Z (e.g. GNOME/MATE/XFCE) discussions are boring. :P -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, Dec 9, 2012 at 2:03 PM, Dan Mashal dan.mashal@gmail.com wrote:
MATE IS growing. And MATE developers are starting to contribute to Gnome. :)
Dan
So is Cinnamon. So is XMonad. So is <spit> Unity, for that matter. What *doesn't* seem to be growing is LXDE, and I'm not sure about XFCE, Enlightenment and WindowMaker. The lightweight window manager / desktop space seems to me to be floundering except for XMonad.
I finally got around to putting a few hours into getting XMonad functional on my Fedora 18 boxes. I haven't quite gotten used to some of its quirks, but at least I'm in a position to compare its memory usage with the other lightweight alternatives. To be blunt, 4 GB *used* to be a lot of RAM but GNOME 3, KDE 4 and Cinnamon are swallowing big chunks of it, and so are Firefox and Chromium / Chrome. I'm beginning to think Google has the right idea with the ChromeBook - shove so much functionality into the browser that you only need an OS to manage the devices. ;-) I want my RAM back!
On 09/12/2012 at 10:03 PM, "Dan Mashal" dan.mashal@gmail.com wrote:
MATE IS growing. And MATE developers are starting to contribute to Gnome. :)
Dan
In the absence of any good reasons *not* to vote for any of the other candidates, and in the face of at least one reason not to vote for you, I'm happy you came last in the board elections.
Now, please stop top-posting. I'm not sure what's more irritating: top posted posts, or that you continue to top-post after 3 people have asked you to stop. It's really not that not hard...
Classy. On Dec 10, 2012 12:14 AM, dave.gibbons2@hushmail.com wrote:
On 09/12/2012 at 10:03 PM, "Dan Mashal" dan.mashal@gmail.com wrote:
MATE IS growing. And MATE developers are starting to contribute to Gnome. :)
Dan
In the absence of any good reasons *not* to vote for any of the other candidates, and in the face of at least one reason not to vote for you, I'm happy you came last in the board elections.
Now, please stop top-posting. I'm not sure what's more irritating: top posted posts, or that you continue to top-post after 3 people have asked you to stop. It's really not that not hard...
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 10/12/2012 at 9:42 AM, "Dan Mashal" dan.mashal@gmail.com wrote:
Classy.
I wasn't going for classy ;) I was hoping to make an impact. But obviously falling on deaf ears.
If anybody else is reading this car-crash thread, thank you for not voting for Dan Mashal. This lad is clearly not material for our board. Communication is an important aspect of our community and his grasp of effective communication is deficient, not to mention his inflammatory behaviour on this mailing list.
Hopefully his communication skills will mature and perhaps he will successfully run for board one day. Thankfully, not today.
On Sat, Dec 08, 2012 at 05:12:27AM -0800, Dan Mashal wrote:
For example, the same thing happened with Gnome 3 upstream where a lot of developers left the project due to a lack of a real vision or direction.
Please don't rely in rant-like blog posts for your source of information. In my impression there are more developers involved in GNOME 3 than ever before.
If you say that developers left, please state their names. I've seen 2 names listed in some blog post before. Those 2 developers were still active (and, yeah, they said so) :P
Could you also not top post (quoting inline is common practice in most mailing lists)?
On 12/08/2012 05:51 AM, Ralf Corsepius wrote:
My primary problem with Fedora isn't "lack of stability", but lack of API/ABI and UI-stability/persistence/sustainability between upgrades.
In other words, I can cope with the number of crashes upgrades typically come along with, but the number "UI-changes" is what makes Fedora difficult to use for me.
I have heard that from users as well with regards to Gnome both 2.x and 3.x as in they have just learned where things are when they are either replaced or removed which forces the user base having to re-learn everything again.
JBG
On 12/09/2012 12:20 AM, "Jóhann B. Guðmundsson" wrote:
On 12/08/2012 05:51 AM, Ralf Corsepius wrote:
My primary problem with Fedora isn't "lack of stability", but lack of API/ABI and UI-stability/persistence/sustainability between upgrades.
In other words, I can cope with the number of crashes upgrades typically come along with, but the number "UI-changes" is what makes Fedora difficult to use for me.
I have heard that from users as well with regards to Gnome both 2.x and 3.x as in they have just learned where things are when they are either replaced or removed which forces the user base having to re-learn everything again.
Please note, I wasn't referring to GUIs (Desktops), but to UIs in general (comprising the command line UIs, as well).
More generally speaking, I am actually referring to me feeling Fedora isn't "keeping the user/installer required learning curse as low" as it should/could be.
Ralf
On 12/08/2012 05:07 AM, M. Edward (Ed) Borasky wrote:
On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG sagarun@gmail.com wrote:
On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
If we want to solve this we need to release an Fedora LTS release for our and the potential other user >base that don't have to/want to update every 6 or 12 months.
Completely agree on this one. In my day job we started using Fedora as one of our desktop os. Then support issues and upgrade cycle started giving nightmares to corp IT. They are looking at other avenues now. I really wish there is a LTS release for this awesome distro - Fedora.
Why does there need to be a long-term support for Fedora? Why not just use Red Hat Enterprise Linux?
Prize + Community which is why so many use RHEL clones instead of Red Hat it self.
Alot of corporate that I know have the policy to only deploy RHEL if the application running on top of the OS lists it as required for support.
If the relevant application does not deploy one of RHEL clones.
I should also mention when I speak of LTS release I'm just speaking of 2 - 3 year release cycle.
If you need anything more than that you certainly should be deploying/using RHEL or one of it's clones.
JBG
On 12/08/2012 12:07 AM, M. Edward (Ed) Borasky wrote:
Completely agree on this one. In my day job we started using Fedora as one of our desktop os. Then support issues and upgrade cycle started giving nightmares to corp IT. They are looking at other avenues now. I really wish there is a LTS release for this awesome distro - Fedora.
Why does there need to be a long-term support for Fedora? Why not just use Red Hat Enterprise Linux?
Fedora is a good initial choice because it has the latest/greatest software set. The problem appears later, because there is no graceful way to switch installed Fedora systems into maintenance mode. This discourages Fedora adoption because it implies a commitment to perpetual upGRADES (as opposed to updates which almost everyone agrees are a necessity in today's world).
By the way, as much as I like RHEL, it also has a difficulty with long term support in a realistic environment where deployed systems age and become less 'important' and actively maintained, until they are not worth paying support for. I suggested to RedHat that they provide a graceful switch-over to CENTOS in such case: it's possible manually anyway, so it would be a nice gesture to do it automatically for customers who let the support expire. As is in our case, this doesn't even decrease the amount of support we purchase---it just gives us the flexibility to deploy new systems all the time.
On Mon, Dec 10, 2012 at 04:20:34PM -0500, Przemek Klosowski wrote:
are not worth paying support for. I suggested to RedHat that they provide a graceful switch-over to CENTOS in such case: it's possible manually anyway, so it would be a nice gesture to do it automatically for customers who let the support expire. As is in our case, this doesn't even decrease the amount of support we purchase---it just gives us the flexibility to deploy new systems all the time.
If CentOS were to take up that effort themselves (largely feasible for them to do technically) I'm sure Red Hat sales would wink in that direction in cases when they felt it was in the interest of Red Hat. Enough of that winking and eventually engineers at Red Hat's end would probably have an incentive to keep it working.
--CJD
On 12/10/2012 09:40 PM, Casey Dahlin wrote:
On Mon, Dec 10, 2012 at 04:20:34PM -0500, Przemek Klosowski wrote:
are not worth paying support for. I suggested to RedHat that they provide a graceful switch-over to CENTOS in such case: it's possible manually anyway, so it would be a nice gesture to do it automatically for customers who let the support expire. As is in our case, this doesn't even decrease the amount of support we purchase---it just gives us the flexibility to deploy new systems all the time.
If CentOS were to take up that effort themselves (largely feasible for them to do technically) I'm sure Red Hat sales would wink in that direction in cases when they felt it was in the interest of Red Hat. Enough of that winking and eventually engineers at Red Hat's end would probably have an incentive to keep it working.
Which is why I think it would be in every ones best interest if all the RHEL clones ( even oracle ) would unite join our community maintain and support Fedora LTS release instead risk being bitten by any business decision Red Hat either willingly or be forced to make.
JBG
On 12/10/2012 05:39 PM, "Jóhann B. Guðmundsson" wrote:
Which is why I think it would be in every ones best interest if all the RHEL clones ( even oracle ) would unite join our community maintain and support Fedora LTS release instead risk being bitten by any business decision Red Hat either willingly or be forced to make.
Community rebuilds of EL or Oracle don't have any interest in Fedora as such. They are interested in a product that provides binary compatibility with EL and Fedora LTS won't do that and if your goal is to protect yourself from Red Hat decisions entirely, using the Fedora brand isn't the ideal choice. More to the point, EL rebuilds are directly affected by whatever changes Red Hat does in EL and as long as they want to retain compatibility, they cannot isolate themselves from it and if they do, lose compatibility, the lose the raison d'etre. You can build a Fedora LTS which merely extends Fedora release by a few months or a couple of years with no goal of retaining EL compatibility and in that case, the community around EL rebuilds won't participate in it.
Rahul
* Przemek Klosowski [10/12/2012 23:08] :
I suggested to RedHat that they
provide a graceful switch-over to CENTOS in such case
When you are considering migrating from distribution A to distribution B, you're probably better off asking distribution B's community to do the work involved.
Emmanuel
Il 07/12/2012 13:53, Tomas Radej ha scritto:
Hi everybody.
[...] A Fedora contributor, Tomas Radej
From the moment I started using Fedora to now, I installed it on 41
different machines of different owners. The unique and most impotant negative feedback I had it when I upgraded a system from Fedora 14 to 15, that was the upgrade from Gnome 2 to Gnome 3. Everything was crashing, a real nightmare. The end of the story? From that moment the owner of that computer has a big problem with *me* (lol). Fedora community should test big transitions like Gnome 2->3 for a longer period of time
On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
The unique and most impotant negative feedback I had it when I upgraded a system from Fedora 14 to 15, that was the upgrade from Gnome 2 to Gnome 3. … Fedora community should test big transitions like Gnome 2->3 for a longer period of time
FWIW if it was running Fedora 14 and the user was content with it, I probably wouldn't have upgraded to Fedora 15. You could have waited 6 months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
I upgrade my *own* machines fairly aggressively — this box has been running Fedora 18 since August 31st for example. But I don't necessarily upgrade everyone's machine to *every* Fedora release.
On 12/07/2012 03:51 PM, David Woodhouse wrote:
On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
The unique and most impotant negative feedback I had it when I upgraded a system from Fedora 14 to 15, that was the upgrade from Gnome 2 to Gnome 3. … Fedora community should test big transitions like Gnome 2->3 for a longer period of time
FWIW if it was running Fedora 14 and the user was content with it, I probably wouldn't have upgraded to Fedora 15. You could have waited 6 months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
I upgrade my *own* machines fairly aggressively — this box has been running Fedora 18 since August 31st for example. But I don't necessarily upgrade everyone's machine to *every* Fedora release.
I know one *nix gray beard that is still running F9 on his workstation because it's setup just the way he likes it and it works for him.
He does not have the time to spare both from work/coding and his personal life to spend hours to setup his system or constantly having to upgrade/re-install fighting and patching whatever nuance that release brings, distracting him from doing actual real work and says that's for GNU/Linux kids, he rather spend that time with his grankids.
His upgrade cycle is tied to the life cycle of his hw...
JBG
On Fri, 2012-12-07 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 12/07/2012 03:51 PM, David Woodhouse wrote:
On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
The unique and most impotant negative feedback I had it when I upgraded a system from Fedora 14 to 15, that was the upgrade from Gnome 2 to Gnome 3. … Fedora community should test big transitions like Gnome 2->3 for a longer period of time
FWIW if it was running Fedora 14 and the user was content with it, I probably wouldn't have upgraded to Fedora 15. You could have waited 6 months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
I upgrade my *own* machines fairly aggressively — this box has been running Fedora 18 since August 31st for example. But I don't necessarily upgrade everyone's machine to *every* Fedora release.
I know one *nix gray beard that is still running F9 on his workstation because it's setup just the way he likes it and it works for him.
He does not have the time to spare both from work/coding and his personal life to spend hours to setup his system or constantly having to upgrade/re-install fighting and patching whatever nuance that release brings, distracting him from doing actual real work and says that's for GNU/Linux kids, he rather spend that time with his grankids.
His upgrade cycle is tied to the life cycle of his hw...
He should have chosen to install RHEL/CentOS/etc... then.
Staying on F9 as a developer is a questionable stance.
Your machine is full of security issues and you could be compromised and become a proxy to compromise the projects you are working on.
If you choose to stay on an older machine you should at least install an OS that gets security updates for a lot longer.
Simo.
On 12/07/2012 04:59 PM, Simo Sorce wrote:
On Fri, 2012-12-07 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 12/07/2012 03:51 PM, David Woodhouse wrote:
On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
The unique and most impotant negative feedback I had it when I upgraded a system from Fedora 14 to 15, that was the upgrade from Gnome 2 to Gnome 3. … Fedora community should test big transitions like Gnome 2->3 for a longer period of time
FWIW if it was running Fedora 14 and the user was content with it, I probably wouldn't have upgraded to Fedora 15. You could have waited 6 months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
I upgrade my *own* machines fairly aggressively — this box has been running Fedora 18 since August 31st for example. But I don't necessarily upgrade everyone's machine to *every* Fedora release.
I know one *nix gray beard that is still running F9 on his workstation because it's setup just the way he likes it and it works for him.
He does not have the time to spare both from work/coding and his personal life to spend hours to setup his system or constantly having to upgrade/re-install fighting and patching whatever nuance that release brings, distracting him from doing actual real work and says that's for GNU/Linux kids, he rather spend that time with his grankids.
His upgrade cycle is tied to the life cycle of his hw...
He should have chosen to install RHEL/CentOS/etc... then.
That's your opinion
Staying on F9 as a developer is a questionable stance.
Not if you know what your are doing
Your machine is full of security issues and you could be compromised and become a proxy to compromise the projects you are working on.
If you choose to stay on an older machine you should at least install an OS that gets security updates for a lot longer.
Oh I mentioned that to him and suggested the same as you are proposing and his response was those that are concern with security are those that don't know how to prevent it.
Given that he made his living punching hole in paper couple of decades ago I know he either back ported relevant patches or fixed it himself if it concerned him cursing modern coders which throw more hw at the problem instead of fixing it while he was at it ( which he did few time when I was working with him ).
He never changed anything ( afaik still does not ) only for the sake of change so it's not like he's against upgrading the machine and does not see the need for doing so once in a while but there just really has to be a real reason for it to happen.
If I would have started arguing with him about it, it was going to be a fight I would have definitely lost and I would have simply been laying there, on his office floor knockout by the entire history of unix or that stack of punch cards from back in the day he had on his desk...
JBG
On Fri, 2012-12-07 at 18:13 +0000, "Jóhann B. Guðmundsson" wrote:
On 12/07/2012 04:59 PM, Simo Sorce wrote:
On Fri, 2012-12-07 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 12/07/2012 03:51 PM, David Woodhouse wrote:
On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
The unique and most impotant negative feedback I had it when I upgraded a system from Fedora 14 to 15, that was the upgrade from Gnome 2 to Gnome 3. … Fedora community should test big transitions like Gnome 2->3 for a longer period of time
FWIW if it was running Fedora 14 and the user was content with it, I probably wouldn't have upgraded to Fedora 15. You could have waited 6 months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
I upgrade my *own* machines fairly aggressively — this box has been running Fedora 18 since August 31st for example. But I don't necessarily upgrade everyone's machine to *every* Fedora release.
I know one *nix gray beard that is still running F9 on his workstation because it's setup just the way he likes it and it works for him.
He does not have the time to spare both from work/coding and his personal life to spend hours to setup his system or constantly having to upgrade/re-install fighting and patching whatever nuance that release brings, distracting him from doing actual real work and says that's for GNU/Linux kids, he rather spend that time with his grankids.
His upgrade cycle is tied to the life cycle of his hw...
He should have chosen to install RHEL/CentOS/etc... then.
That's your opinion
Of course, I do not claim to posses *the truth*
Staying on F9 as a developer is a questionable stance.
Not if you know what your are doing
Self maintenance is *certainly* more time consuming than updating Fedora releases and relying on the work of others if you are talking about security.
Oh I mentioned that to him and suggested the same as you are proposing and his response was those that are concern with security are those that don't know how to prevent it.
Yeah and I am Batman, sorry let's just drop this I shouldn't have replied at all.
Given that he made his living punching hole in paper couple of decades ago I know he either back ported relevant patches or fixed it himself if it concerned him cursing modern coders which throw more hw at the problem instead of fixing it while he was at it ( which he did few time when I was working with him ).
He never changed anything ( afaik still does not ) only for the sake of change so it's not like he's against upgrading the machine and does not see the need for doing so once in a while but there just really has to be a real reason for it to happen.
If I would have started arguing with him about it, it was going to be a fight I would have definitely lost and I would have simply been laying there, on his office floor knockout by the entire history of unix or that stack of punch cards from back in the day he had on his desk...
I do not care ab out arguing with him, I care to give advice to others (if they care for my advice, feel free to fully ignore).
Don't follow that model, it's broken security wise, unless you keep your machine disconnected from the network.
Simo.
On 12/07/2012 06:58 PM, Simo Sorce wrote:
I do not care ab out arguing with him, I care to give advice to others (if they care for my advice, feel free to fully ignore).
Don't follow that model, it's broken security wise, unless you keep your machine disconnected from the network.
In the end if you are going to keep your machine secure et all you have to keep it disconnected there will always be bugs which can be exploited when you are network connected ;)
I personally think people should start worrying more about application they install on their mobile devices ( which they more often then not grant access to privacy information themselves ) or information they expose themselves on various social network sites willingly, unaware of the consequences it might have then having their OS cracked.
If I was a crook I would simply use various online tracking sites or social networking sites to monitor whether you are home or not and simply rob you when your post on your status that you have gone on holidays next to the picture of your house tagged with the geographical coordinates to it or when an app places you on Starbucks.
Or I would collect all those idiotic question people have to provide answer on various online sites including banks cross reference them to you social network pages and your posts, then simply call your bank, provide answer to those questions and wipe your account clean.
Much more simpler, probably pays better of in the end and harder to track down compared to cracking your laptop OS or explode a bug which requires you to be a skilled programmer or cryptography engineer to pull it of..
Seriously why bother cracking people OS to get to this information when it gets handed to you on silver platter by the individuals themselves online?
JBG
"There's a war out there, old friend. A world war. And it's not about who's got the most bullets. It's about who controls the information. What we see and hear, how we work, what we think... it's all about the information!" Cosmo
On 12/07/2012 03:08 PM, "Jóhann B. Guðmundsson" wrote:
In the end if you are going to keep your machine secure et all you have to keep it disconnected there will always be bugs which can be exploited when you are network connected ;)
Smiley doesn't change the inane argument.
We don't with absolutes when it comes to security. Fedora with updates is *more* secure than a Fedora version which doesn't get any updates any more. Therefore, in general it is a bad idea to run a unmaintained Fedora on a system that is connected to the network.
Rahul
Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, I'll bite.
This sort of conversation often comes and goes without much being done. Usually it consists of debates between three camps:
1. Those who see Fedora as an intrinsically unstable distro which showcases and attracts testing for the latest upstream work 2. Those who want Fedora to be stable enough to become a realistic alternative to Windows and Ubuntu for the general masses 3. Those who want Fedora to be stable enough and supported for long enough to be used as a server OS
I think the reason nothing happens is due to the core issue not being agreed upon by all camps. It's very difficult to make progress on a solution unless you first understand and agree on the problem.
However, if you're still interested I've laid out some ideas, based on my belief that instability is a significant problem, below.
On 07/12/12 12:53, Tomas Radej wrote:
One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work.
One hypothesis is that too few people use Rawhide to a point where enough testing gets done before final releases. I think making some basic guarantees about Rawhide's stability (it boots, package management works, etc.) would go some way to increase early adoption and ensure bugs are reported and fixed before final releases, thus avoiding many unnecessary updates. I would certainly consider running Rawhide with such guarantees.
Once most of us are dog-fooding Rawhide the temptation to release the latest unstable upstream code in stable release updates would be significantly reduced and our update policy could be tightened to disallow version bumps, etc. in stable release updates similar to other, more popular distros' update policies.
I think this is a better first step forward than LTS releases because it focuses on users' first impressions of Fedora by increasing the stability level on the day of release.
Andy
On 12/07/2012 03:11 PM, Andrew Price wrote:
Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, I'll bite.
This sort of conversation often comes and goes without much being done. Usually it consists of debates between three camps:
- Those who see Fedora as an intrinsically unstable distro which
showcases and attracts testing for the latest upstream work 2. Those who want Fedora to be stable enough to become a realistic alternative to Windows and Ubuntu for the general masses 3. Those who want Fedora to be stable enough and supported for long enough to be used as a server OS
I think the reason nothing happens is due to the core issue not being agreed upon by all camps. It's very difficult to make progress on a solution unless you first understand and agree on the problem.
Fedora LTS first and foremost needs maintainers willing to commit to it.
However, if you're still interested I've laid out some ideas, based on my belief that instability is a significant problem, below.
On 07/12/12 12:53, Tomas Radej wrote:
One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work.
One hypothesis is that too few people use Rawhide to a point where enough testing gets done before final releases. I think making some basic guarantees about Rawhide's stability (it boots, package management works, etc.) would go some way to increase early adoption and ensure bugs are reported and fixed before final releases, thus avoiding many unnecessary updates. I would certainly consider running Rawhide with such guarantees.
Once most of us are dog-fooding Rawhide the temptation to release the latest unstable upstream code in stable release updates would be significantly reduced and our update policy could be tightened to disallow version bumps, etc. in stable release updates similar to other, more popular distros' update policies.
I think this is a better first step forward than LTS releases because it focuses on users' first impressions of Fedora by increasing the stability level on the day of release.
If you want to improve "Rawhide" and it's stability get developers/maintainers to run rawhide on their daily bases.
Not going to happened afaik.
JBG
On Fri, Dec 07, 2012 at 03:11:31PM +0000, Andrew Price wrote:
Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, I'll bite.
This sort of conversation often comes and goes without much being done. Usually it consists of debates between three camps:
- Those who see Fedora as an intrinsically unstable distro which
showcases and attracts testing for the latest upstream work 2. Those who want Fedora to be stable enough to become a realistic alternative to Windows and Ubuntu for the general masses 3. Those who want Fedora to be stable enough and supported for long enough to be used as a server OS
Hmmm. I don't think I'm in any of those camps. I want Fedora to thrive and be used, not as an "alternative" but on its own merits. That includes being a general-purpose OS, both on desktops, on traditional servers, and in the cloud. It doesn't necessarily mean "the general masses" nor world domination.
While I *do* think we would benefit from a slightly longer cycle (with an "security updates only" phase), I don't think that's the only way to tackle the problem.
For example, making it so key applications and development stacks could easily float from one base OS to the next would make it less of an issue when the base OS needs to be upgraded.
Making upgrades incredibly painless is another good but different approach, making us closer to a rolling release. (I think we're headed that way with 'fedup', but it's going to be a little longer for that to shake out.)
On 07/12/12 17:48, Matthew Miller wrote:
On Fri, Dec 07, 2012 at 03:11:31PM +0000, Andrew Price wrote:
Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, I'll bite.
This sort of conversation often comes and goes without much being done. Usually it consists of debates between three camps:
- Those who see Fedora as an intrinsically unstable distro which
showcases and attracts testing for the latest upstream work 2. Those who want Fedora to be stable enough to become a realistic alternative to Windows and Ubuntu for the general masses 3. Those who want Fedora to be stable enough and supported for long enough to be used as a server OS
Hmmm. I don't think I'm in any of those camps. I want Fedora to thrive and be used, not as an "alternative" but on its own merits.
Each OS is an alternative to the others. "Alternative" here shouldn't imply anything negative, simply that users could happily switch from one to the other.
That includes being a general-purpose OS, both on desktops, on traditional servers, and in the cloud.
Well that's my hope, too. The items on your list are compatible with each other but the problem arises when you add the requirement for Fedora to additionally be an unstable mixing pot of the latest upstream packages. And that's really what rawhide should be, but since rawhide requires so much effort to install and keep running, that's what Fedora proper has become.
While I *do* think we would benefit from a slightly longer cycle (with an "security updates only" phase), I don't think that's the only way to tackle the problem.
I'm not against extending the cycle in essence. I just don't think the *first* step should be to extend cycles and/or support. I think we need the ability to tackle as many stability problems as we can, pre-release, before we can start thinking about extending life cycles, and that means getting people using rawhide day-to-day again. The more bugs we allow into our releases by neglecting to test rawhide, the more development time we have to spend/waste on fixing packages in the three supported releases.
I would link to http://lwn.net/Articles/506831/ but you were quoted in that article so I'm guessing you've already seen it :)
For example, making it so key applications and development stacks could easily float from one base OS to the next would make it less of an issue when the base OS needs to be upgraded.
Not sure I catch your drift here, but it sounds like it could cause API mismatch headaches.
Making upgrades incredibly painless is another good but different approach, making us closer to a rolling release. (I think we're headed that way with 'fedup', but it's going to be a little longer for that to shake out.)
Yep, I upgraded my netbook to f18 beta with fedup yesterday without too much hassle. Looks promising.
Andy
For example, making it so key applications and development stacks could
easily float from one base OS to the next would make it less of an issue when the base OS needs to be upgraded.
Not sure I catch your drift here, but it sounds like it could cause API mismatch headaches.
It underscores the need for the base OS or core to be absolutely as small as possible. FreeBSD provides a good model, small installed system customized with packages/ports. Personally I would like to see a three-level approach:
Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest. Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster. Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
A major change to one level should cause a rebuild of higher layers to avoid the API issues you mention. Changes within a layer should be independent. I would propose change rates of:
Level 1 - 12-18 mos Level 2 - 6-12 mos Level 3 - release as soon as stable packages are available.
On 12/07/2012 08:26 PM, Mark Bidewell wrote:
It underscores the need for the base OS or core to be absolutely as small as possible. FreeBSD provides a good model, small installed system customized with packages/ports. Personally I would like to see a three-level approach:
Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest. Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster. Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
A major change to one level should cause a rebuild of higher layers to avoid the API issues you mention. Changes within a layer should be independent. I would propose change rates of:
Level 1 - 12-18 mos Level 2 - 6-12 mos Level 3 - release as soon as stable packages are available.
IMHO it is not the "level" of things which is problematic. I have no problem with rapid updates for the kernel (great for hardware support and bug fixes), or for X11 (same reasons), gcc upgrades never gave me problems, I like the fast updates to KDE.
There are two things which are problematic:
1) projects undergoing great revolutions. They are quickly absorbed by Fedora and all the immaturity issues of the projects cast shadows on Fedora. Two examples: GNOME 2->3, KDE 3->4; exactly the same problem, upstream changing everything and users unhappy about the results (even if different answers were given by KDE ("wait, we will readd what is missing") and by GNOME ("forget what is missing, this is how it will be"). Obviously a regression of the desktop environment is not a small detail for end users (read: "Fedora doesn't work").
2) revolutions at the system level. Things that replace other things and everything changes: command line tools, GUIs, config files, logs, ... Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld. These projects sometimes have bugs (being in their infancy), often are badly documented and are always completely unknown by end users; the result is that things "do not work" and "who knows how this should be fixed". In many cases the impact on the collateral utilities (dracut, system-config-*, anaconda, ...) contribute to the chaos.
As a final consideration, the fixability of the issues is important. I can easily revert to a previous kernel, I can less easily throw away pulseaudio, and I can in no way fix GNOME 3.
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and never stepping up as Fedora packager because too scared by the bureaucracy)
On 12/08/2012 01:48 PM, Roberto Ragusa wrote:
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and never stepping up as Fedora packager because too scared by the bureaucracy)
Can you be more specific? What sort of bureaucracy do you think is avoidable in the current process? What would it take for you to get started?
Rahul
On 12/08/2012 07:52 PM, Rahul wrote:
On 12/08/2012 01:48 PM, Roberto Ragusa wrote:
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and never stepping up as Fedora packager because too scared by the bureaucracy)
Can you be more specific? What sort of bureaucracy do you think is avoidable in the current process? What would it take for you to get started?
I do not have specific suggestions, as I actually do not know the process well, and even less the motivations behind each steps.
I can only say that at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 23 steps are shown under "Becoming a Fedora Package Collection Maintainer".
Some of them are technical and more or less unavoidable (koji, expiring certificates, scm, bodhi), others are more social (ask a review, introduce, inform upstream, get sponsorship), finally there is legal stuff (the CLA).
My enthusiasm has never been powerful enough to overcome such an amount of static friction. I do not have a bag of packages to add to Fedora, so going through all the steps just to maintain one rpm or two is costly. I'm sure that after being "inside" the willingness to do more will raise easily, but the initial investment appears unjustified. Replying to random posts on the MLs or contributing patches to random projects is more appealing (write mail, click send, finished).
On 12/09/2012 12:21 PM, Roberto Ragusa wrote:
I can only say that at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 23 steps are shown under "Becoming a Fedora Package Collection Maintainer". Some of them are technical and more or less unavoidable (koji, expiring certificates, scm, bodhi), others are more social (ask a review, introduce, inform upstream, get sponsorship), finally there is legal stuff (the CLA). My enthusiasm has never been powerful enough to overcome such an amount of static friction.
It is a fairly long process but I don't think we have added any unnecessary steps. We have people including me who have guided several new contributors through the process and if there is anything we can do to reduce the friction, we would be happy to take suggestions which are specific
Rahul
2012/12/9 Roberto Ragusa mail@robertoragusa.it:
On 12/08/2012 07:52 PM, Rahul wrote:
On 12/08/2012 01:48 PM, Roberto Ragusa wrote:
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and never stepping up as Fedora packager because too scared by the bureaucracy)
Can you be more specific? What sort of bureaucracy do you think is avoidable in the current process? What would it take for you to get started?
I do not have specific suggestions, as I actually do not know the process well, and even less the motivations behind each steps.
Maybe there could be some "hire a packager" program :-)
I can only say that at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 23 steps are shown under "Becoming a Fedora Package Collection Maintainer".
Some of them are technical and more or less unavoidable (koji, expiring certificates, scm, bodhi), others are more social (ask a review, introduce, inform upstream, get sponsorship), finally there is legal stuff (the CLA).
Personally I like this model because in the end it translates to higher quality packages (the social stuff), and with more people looking at it, unlikely to allow passing some issues like dubious license, failing make check, failing to pass proper compiler/loader flags, etc. Otherwise, to lift most of it, it would be required to encourage personal repositories or some kind of "contrib" repository.
My enthusiasm has never been powerful enough to overcome such an amount of static friction. I do not have a bag of packages to add to Fedora, so going through all the steps just to maintain one rpm or two is costly. I'm sure that after being "inside" the willingness to do more will raise easily, but the initial investment appears unjustified.
Once you get used to the several steps it also becomes easier, but the learning curve is not simple, and I believe most "mentor capable" people are overworked, so, hard to get someone to babysit the first steps :-)
Paulo
On Sun, 09 Dec 2012 18:21:43 +0100, Roberto Ragusa wrote:
I can only say that at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers 23 steps are shown under "Becoming a Fedora Package Collection Maintainer".
Some of them are technical and more or less unavoidable (koji, expiring certificates, scm, bodhi), others are more social (ask a review, introduce, inform upstream, get sponsorship), finally there is legal stuff (the CLA).
Some are very small steps and only a very small hurdle.
If you give up so early, it's likely that you would give up quickly also later when you are confronted with typical problems during ordinary package maintenance. For example, some packagers would be fed up as soon as they run into issues with Fedora Project development (arbitrary stuff they don't like or don't agree with), or Fedora infrastructure (even if just something like the move from cvs to git and a fundamental change in the tools being used), or other maintainers modifying their packages (even if following guidelines), or package dependencies causing build failures or run-time failures, or non-responsive bug reporters, … not limited to that.
My enthusiasm has never been powerful enough to overcome such an amount of static friction. I do not have a bag of packages to add to Fedora, so going through all the steps just to maintain one rpm or two is costly.
It has been mentioned a couple of times in past and similar discussions that the "How to join" guidelines are just a recommendation, a way that should work, but not the only way how to find a sponsor and how to become a maintainer/co-maintainer.
It should be obvious that if somebody else already has packaged something for Fedora before, which you would also like to package, you cannot use such packages for Fedora Package Review requests. Still, you can contact the existing maintainer(s), offer help, tell about your plan of joining as a co-maintainer and ask them about their opinion. Even better if you contribute to the package regularly. It could be that they would welcome the offer and might sponsor you directly, so you could go ahead with package maintenance directly and prove that you are familiar with packaging and with how things are done at Fedora. In other cases, you would still need to find a separate sponsor, *but* there are ways to do that without any package review requests, especially if there is an agreement with existing package maintainer(s).
I'm sure that after being "inside" the willingness to do more will raise easily, but the initial investment appears unjustified.
IMO, not seldomly it's the opposite. The "initial investment" is an effort you would need to go through only once. Once you are responsible for a package, however, you may need to show a lot more motivation as not become one of those, who have managed to join too easily and leave the project silently once a first roadblock is met.
Replying to random posts on the MLs or contributing patches to random projects is more appealing (write mail, click send, finished).
It's much more convenient, requires no dedicated commitment, you can stop any time. That's true. Especially if an upstream maintainer is much more responsive than a Fedora maintainer and your patch in Fedora bugzilla seems to be ignored, you may enjoy that more. Don't forget the added convenience of being able to touch Fedora packages yourself and not having to wait for somebody else.
On Sat, Dec 8, 2012 at 1:48 PM, Roberto Ragusa mail@robertoragusa.itwrote:
On 12/07/2012 08:26 PM, Mark Bidewell wrote:
It underscores the need for the base OS or core to be absolutely as
small as possible. FreeBSD provides a good model, small installed system customized with packages/ports. Personally I would like to see a three-level approach:
Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and
libc - moves the slowest.
Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11,
KDE/QT, GNOME, etc - moves faster.
Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
A major change to one level should cause a rebuild of higher layers to
avoid the API issues you mention. Changes within a layer should be independent. I would propose change rates of:
Level 1 - 12-18 mos Level 2 - 6-12 mos Level 3 - release as soon as stable packages are available.
IMHO it is not the "level" of things which is problematic. I have no problem with rapid updates for the kernel (great for hardware support and bug fixes), or for X11 (same reasons), gcc upgrades never gave me problems, I like the fast updates to KDE.
There are two things which are problematic:
- projects undergoing great revolutions. They are quickly absorbed
by Fedora and all the immaturity issues of the projects cast shadows on Fedora. Two examples: GNOME 2->3, KDE 3->4; exactly the same problem, upstream changing everything and users unhappy about the results (even if different answers were given by KDE ("wait, we will readd what is missing") and by GNOME ("forget what is missing, this is how it will be"). Obviously a regression of the desktop environment is not a small detail for end users (read: "Fedora doesn't work").
- revolutions at the system level. Things that replace other things and
everything changes: command line tools, GUIs, config files, logs, ... Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld. These projects sometimes have bugs (being in their infancy), often are badly documented and are always completely unknown by end users; the result is that things "do not work" and "who knows how this should be fixed". In many cases the impact on the collateral utilities (dracut, system-config-*, anaconda, ...) contribute to the chaos.
As a final consideration, the fixability of the issues is important. I can easily revert to a previous kernel, I can less easily throw away pulseaudio, and I can in no way fix GNOME 3.
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and never stepping up as Fedora packager because too scared by the bureaucracy)
-- Roberto Ragusa mail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I hear you. I will admit I haven't thought through all of the possible permutations. Probably a better criterion would be impact of ABI changes. What I would like to see changed is the fact that, right now (and this goes for all Linux distros), if you want to have the smallest probability of upgrade issues, all packages must upgrade at once - preferably with a clean install. On other OSs, If I want a new version of Libreoffice I can download and install it. On Linux, your choices are: 1) Install from source or packages may be available from the developer and take the risk that they might not play nice with the rest of the system. 2) Wait for the next OS release.
It seems like there should be some way to improve this situation.
Hi,
On Sat, Dec 08, 2012 at 05:45:25PM -0500, Mark Bidewell wrote:
I hear you. I will admit I haven't thought through all of the possible permutations. Probably a better criterion would be impact of ABI changes. What I would like to see changed is the fact that, right now (and this goes for all Linux distros), if you want to have the smallest probability of upgrade issues, all packages must upgrade at once - preferably with a clean install. On other OSs, If I want a new version of Libreoffice I can download and install it.
http://www.libreoffice.org/download/
On Linux, your choices are:
- Install from source or packages may be available from the developer and
take the risk that they might not play nice with the rest of the system.
Which is not really different from how it works on other OSes, is it?
The linux packages (.rpm, .deb) from the URL mentioned above bundle ~all libs except libc.so and install into /opt.
- Wait for the next OS release.
3) do the necessary work and build the packages yourself (bonus point: publish them in a repo for other people who might want to use newer libreoffice in old Fedora)
D.
On Fri, Dec 07, 2012 at 01:53:50PM +0100, Tomas Radej wrote:
community, I am seeking support for a movement, both collective and individual, that would improve communication, cooperation and generally the life of Fedora on the most fundamental basis.
In case it's not clear, I'm in. :)
2012/12/7 Tomas Radej tradej@redhat.com:
The threat for Fedora is that even in the FOSS, there is competition. Distros are competing for users - users that give back, users that report bugs, or users that are or become maintainers and developers. When the overwhelming response to Fedora is "Hey, they've got some neat features, but I need it to work, so that's why I'm using XYZ instead", the user/dev base is going to wither and move elsewhere.
I believe one of the major issues is some lack of proper usability tests. To get it done by volunteers, I would suggest something like a very simple way to setup a VM and test there. Personally, I test, but not consistently neither reporting bugs, etc, several distros in VirtualBox, because it is very easy to setup after downloading the install ISO.
I am also running rawhide in my main desktop at home. Example of my life as a rawhide user for almost one year:
[non booting rawhide kernels and now breaking last booting kernel] https://bugzilla.redhat.com/show_bug.cgi?id=827734 [after upgrading to rawhide, fedora fails to boot into installed system] https://bugzilla.redhat.com/show_bug.cgi?id=789285
It is ok to have some things broken for a small window of time in the development branch, not good if one ends up with 3 consecutive non booting kernel updates of course, but anyway, for most contributors it is better to run rawhide in a VM, but the more stable it is kept, the better, because if things get too broken, people will give up in reporting and triaging problems.
Paulo
2012/12/7 Tomas Radej tradej@redhat.com:
Hi everybody.
Disclaimer: This mail is written from the position of a Fedora community member. Red Hat has nothing to do with this.
For those who doesn't bother reading this - "stability vs. innovation" rant.
Tomas, why don't you just use/recomment stable distro?
On Sun, Dec 09, 2012 at 11:04:41AM +0300, Peter Lemenkov wrote:
2012/12/7 Tomas Radej tradej@redhat.com:
Hi everybody.
Disclaimer: This mail is written from the position of a Fedora community member. Red Hat has nothing to do with this.
For those who doesn't bother reading this - "stability vs. innovation" rant.
Quite easy. Ubuntu LTS succeeds where Fedora (and normal Ubuntu) fails. Moreover, extending the support cycle to five years was a brilliant move from Ubuntu. Red Hat and its derivatives do not really compete in the same field.
I too used to use Fedora but the so-called innovation is too demanding to keep up with.
- Jukka.
Fedora 14 works great still.
On Sun, Dec 9, 2012 at 12:21 AM, Jukka Ruohonen jruohonen@iki.fi wrote:
On Sun, Dec 09, 2012 at 11:04:41AM +0300, Peter Lemenkov wrote:
2012/12/7 Tomas Radej tradej@redhat.com:
Hi everybody.
Disclaimer: This mail is written from the position of a Fedora community member. Red Hat has nothing to do with this.
For those who doesn't bother reading this - "stability vs. innovation"
rant.
Quite easy. Ubuntu LTS succeeds where Fedora (and normal Ubuntu) fails. Moreover, extending the support cycle to five years was a brilliant move from Ubuntu. Red Hat and its derivatives do not really compete in the same field.
I too used to use Fedora but the so-called innovation is too demanding to keep up with.
- Jukka.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Am 09.12.2012 09:57, schrieb Dan Mashal:
Fedora 14 works great still.
and who the hell is fixing security bugs for your Fedora 14? a osversion with a lot of known security holes can not work great by definition and so because the 6 months release cycle fedora should also respect the users point of view and not only the developers because a distribution without users will sooner or later die
I dont care.
On Sun, Dec 9, 2012 at 2:31 AM, Reindl Harald h.reindl@thelounge.netwrote:
Am 09.12.2012 09:57, schrieb Dan Mashal:
Fedora 14 works great still.
and who the hell is fixing security bugs for your Fedora 14? a osversion with a lot of known security holes can not work great by definition and so because the 6 months release cycle fedora should also respect the users point of view and not only the developers because a distribution without users will sooner or later die
Am 09.12.2012 11:32, schrieb Dan Mashal:
I dont care.
On Sun, Dec 9, 2012 at 2:31 AM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
Am 09.12.2012 09:57, schrieb Dan Mashal: > Fedora 14 works great still. and who the hell is fixing security bugs for your Fedora 14? a osversion with a lot of known security holes can not work great by definition and so because the 6 months release cycle fedora should also respect the users point of view and not only the developers because a distribution without users will sooner or later die
so if you do not care about security as also not top-posting you should simply be quiet because in this case you are on the wrong mailing-list and should consider NOT connect your computers to the inernet at all because irresponsible people like you and their zombies are one of the biggest problems
On Sun, 9 Dec 2012 02:32:41 -0800 Dan Mashal dan.mashal@gmail.com wrote:
On Sun, Dec 9, 2012 at 2:31 AM, Reindl Harald h.reindl@thelounge.netwrote:
and who the hell is fixing security bugs for your Fedora 14? a osversion with a lot of known security holes can not work great by definition and so because the 6 months release cycle fedora should also respect the users point of view and not only the developers because a distribution without users will sooner or later die
I dont care.
As an outsider to Fedora Devel work. I would be quite worried if "I don't care" was coming across as a de-facto position, of those involved in the distro.
Regards, Frank
May I remind you that F14 is END OF LIFE? Sure I'd love for f14 to continue getting updates. But it's not a "long term support" release.
Dan
On Sunday, December 9, 2012, Frank Murphy wrote:
On Sun, 9 Dec 2012 02:32:41 -0800 Dan Mashal <dan.mashal@gmail.com javascript:;> wrote:
On Sun, Dec 9, 2012 at 2:31 AM, Reindl Harald <h.reindl@thelounge.net javascript:;>wrote:
and who the hell is fixing security bugs for your Fedora 14? a osversion with a lot of known security holes can not work great by definition and so because the 6 months release cycle fedora should also respect the users point of view and not only the developers because a distribution without users will sooner or later die
I dont care.
As an outsider to Fedora Devel work. I would be quite worried if "I don't care" was coming across as a de-facto position, of those involved in the distro.
Regards, Frank -- devel mailing list devel@lists.fedoraproject.org javascript:; https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, 9 Dec 2012 03:30:08 -0800 Dan Mashal dan.mashal@gmail.com wrote:
May I remind you that F14 is END OF LIFE? Sure I'd love for f14 to continue getting updates. But it's not a "long term support" release.
Dan
Huh!,
Please read your own posts back in order.
Regards, Frank
Am 09.12.2012 12:30, schrieb Dan Mashal:
May I remind you that F14 is END OF LIFE? Sure I'd love for f14 to continue getting updates. But it's not a "long term support" release.
On Sunday, December 9, 2012, Frank Murphy wrote:
On Sun, 9 Dec 2012 02:32:41 -0800 Dan Mashal <dan.mashal@gmail.com > > >On Sun, Dec 9, 2012 at 2:31 AM, Reindl Harald > > and who the hell is fixing security bugs for your Fedora 14? > > a os version with a lot of known security holes can not work > > great by definition and so because the 6 months release > > cycle fedora should also respect the users point of view > > and not only the developers because a distribution without > > users will sooner or later die > > I dont care. As an outsider to Fedora Devel work. I would be quite worried if "I don't care" was coming across as a de-facto position, of those involved in the distro.
may i remind you that you said "Fedora 14 works great still" your ignorance and "i do not care" attitude about security and top-posting should make clear that you are the wrong person for any responsiblity
people like you are the root cause for many problems in the developemt all over the years
-------- Original-Nachricht -------- Betreff: Re: Where are we going? (Not a rant) Datum: Sun, 9 Dec 2012 00:57:10 -0800 Von: Dan Mashal dan.mashal@gmail.com Antwort an: Development discussions related to Fedora devel@lists.fedoraproject.org An: jruohonen@iki.fi, Development discussions related to Fedora devel@lists.fedoraproject.org
Fedora 14 works great still.
People like me? You don't even know me, who I am or what I'm about. Don't try to blame Fedora's problems on me. I've been a contributor since January 2012. And in the last 12 months my accomplishments speak for themselves. I don't claim to be perfect.
Do I care about f14 getting security updates? NO. Would it be NTH? YES.
Dan
On Sunday, December 9, 2012, Reindl Harald wrote:
Am 09.12.2012 12:30, schrieb Dan Mashal:
May I remind you that F14 is END OF LIFE? Sure I'd love for f14 to continue getting updates. But it's not a "long term support" release.
On Sunday, December 9, 2012, Frank Murphy wrote:
On Sun, 9 Dec 2012 02:32:41 -0800 Dan Mashal <dan.mashal@gmail.com <javascript:;> > > >On Sun, Dec 9, 2012 at 2:31 AM, Reindl Harald > > and who the hell is fixing security bugs for your Fedora 14? > > a os version with a lot of known security holes can not work > > great by definition and so because the 6 months release > > cycle fedora should also respect the users point of view > > and not only the developers because a distribution without > > users will sooner or later die > > I dont care. As an outsider to Fedora Devel work. I would be quite worried if "I don't care" was coming across as a de-facto position, of those involved in the distro.
may i remind you that you said "Fedora 14 works great still" your ignorance and "i do not care" attitude about security and top-posting should make clear that you are the wrong person for any responsiblity
people like you are the root cause for many problems in the developemt all over the years
-------- Original-Nachricht -------- Betreff: Re: Where are we going? (Not a rant) Datum: Sun, 9 Dec 2012 00:57:10 -0800 Von: Dan Mashal <dan.mashal@gmail.com javascript:;> Antwort an: Development discussions related to Fedora < devel@lists.fedoraproject.org javascript:;> An: jruohonen@iki.fi javascript:;, Development discussions related to Fedora <devel@lists.fedoraproject.org javascript:;>
Fedora 14 works great still.
On Sun, Dec 9, 2012 at 12:21 AM, Jukka Ruohonen jruohonen@iki.fi wrote:
Quite easy. Ubuntu LTS succeeds where Fedora (and normal Ubuntu) fails. Moreover, extending the support cycle to five years was a brilliant move from Ubuntu. Red Hat and its derivatives do not really compete in the same field.
I too used to use Fedora but the so-called innovation is too demanding to keep up with.
- Jukka.
Ubuntu is on the verge of pissing away years of goodwill by
a. Making a bizarre fork of GNOME 3 its default desktop b. Integrating an app store, a music store and Amazon search into said desktop c. Releasing a 12.10 that just barely functioned on some configurations.
They've also been slowly backing away from their commitments over the years. They used to ship free install media; they don't any more. They've even got a $16 "suggested donation" form on their download page. I have no confidence that the 10.04 LTS support will be there now that there's a 12.04 LTS.
On Sun, 9 Dec 2012 11:04:41 +0300 Peter Lemenkov lemenkov@gmail.com wrote:
For those who doesn't bother reading this - "stability vs. innovation" rant.
Tomas, why don't you just use/recomment stable distro?
Sometimes, you want innovation + stability. I usually end up with xubuntu for those people, who ask me about Linux. After having shown them my setups with Fedora (Xfce), and running the various LiveCD spins.(incl Gnome)
Regards, Frank -- I am as nothing in life's chain. --Frank
On 12/07/2012 11:53 PM, Tomas Radej wrote:
One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work.
I know this is an old thread, but I'm curious as to what didn't "really work" for them.
Was it instability? Lack of media support? Non-free software like nvidia drivers or flash? Devices not working, lack of proprietary firmware? Problems/complications with the installer?
The one thing that I personally think is missing is excellent upgrade support between releases via the package manager (and I know that Richard has been working on this with packagekit). This might make Fedora more attractive.
I'm also surprised to read of lots of people saying Fedora is not reliable as I have rarely had any problems, certainly less than I recall having on Ubuntu.
-c
Chris Smart schreef, Op 2-1-2013 8:53:
On 12/07/2012 11:53 PM, Tomas Radej wrote:
One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work.
I know this is an old thread, but I'm curious as to what didn't "really work" for them.
Was it instability? Lack of media support? Non-free software like nvidia drivers or flash? Devices not working, lack of proprietary firmware? Problems/complications with the installer?
The one thing that I personally think is missing is excellent upgrade support between releases via the package manager (and I know that Richard has been working on this with packagekit). This might make Fedora more attractive.
I'm also surprised to read of lots of people saying Fedora is not reliable as I have rarely had any problems, certainly less than I recall having on Ubuntu.
-c
For me it's the nvidia driver. With my gf220 card it makes upgrading a hell. Installing nvidia's non-free driver fixes the problem, and after that everything is fine. You have been lucky with your hardware. A lot of people run (the latest) Fedora in a VM, which doesn't help for testing hardware support.
regards,