I tried upgrading my system using the DVD, Netinstall CD, and Preupgrade. Each time boot got stuck at the line "Trying to unpack rootfs image as initramfs. . . ". It seems that the installer files have gotten fatter and more memory is required.
This is a known problem, http://fossplanet.com/f13/fedora-15-i386-netinst-iso-problems-158445/, but no one on the Fedora QA or Documentation team thought that it was material to add to the Release Notes.
Hope this helps.
On 05/25/2011 10:44 AM, Kam Leo wrote:
I tried upgrading my system using the DVD, Netinstall CD, and Preupgrade. Each time boot got stuck at the line "Trying to unpack rootfs image as initramfs. . . ". It seems that the installer files have gotten fatter and more memory is required.
When I checked http://fedoraproject.org/ yesterday, it said that Fedora 15 required 500 MB RAM; now, it says 768. I don't know if the Release Notes have been updated yet, but it's right there on their home page.
On Wed, May 25, 2011 at 2:40 PM, Joe Zeff joe@zeff.us wrote:
On 05/25/2011 10:44 AM, Kam Leo wrote:
It seems that the installer files have gotten fatter and more memory is required.
When I checked http://fedoraproject.org/ yesterday, it said that Fedora 15 required 500 MB RAM; now, it says 768. I don't know if the Release Notes have been updated yet, but it's right there on their home page.
There are more details here: https://bugzilla.redhat.com/show_bug.cgi?id=682555
Mike
On Wed, May 25, 2011 at 12:20 PM, Mike Williams dmikewilliams@gmail.com wrote:
On Wed, May 25, 2011 at 2:40 PM, Joe Zeff joe@zeff.us wrote:
On 05/25/2011 10:44 AM, Kam Leo wrote:
It seems that the installer files have gotten fatter and more memory is required.
When I checked http://fedoraproject.org/ yesterday, it said that Fedora 15 required 500 MB RAM; now, it says 768. I don't know if the Release Notes have been updated yet, but it's right there on their home page.
There are more details here: https://bugzilla.redhat.com/show_bug.cgi?id=682555
Mike
After reading the bug report I can only shake my head.
1. The problem was known at least a month before the release date. 2. QA feels that they're powerless to flag this problem as a show stopper. 3. Release Notes have long lead times and are no longer suitable for flagging important last minute changes in system requirements.
On 05/26/2011 02:46 AM, Kam Leo wrote:
After reading the bug report I can only shake my head.
- The problem was known at least a month before the release date.
Yes. As noted in the bug report, a change in the installer and related components are going in for Fedora 16 but the amount of change was considered too disruptive by the installer team to risk pushing in a change just a month before release. Note that Fedora 15 development is already on a code freeze at that time and only important and confined bug fixes are supposed to be pushed in at that point. This bug fix won't be confined and requires significant changes in many components. Those are very risky to push through one month before the release in a installer.
- QA feels that they're powerless to flag this problem as a show stopper.
QA works against a well documented and publicized release criteria that gets frequent updates via test list
http://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
In particular, the installer in Fedora 14 already required more memory in some cases and this isn't considered a show stopper bug to block the release as per the release criteria.
- Release Notes have long lead times and are no longer suitable for
flagging important last minute changes in system requirements.
Fedora doesn't rely on only the release notes. There are other places including the common bugs page which is linked from the release announcement and other prominent places.
https://fedoraproject.org/wiki/Common_F15_bugs#Installation_requires_more_me...
Rahul
On 05/25/2011 02:16 PM, Kam Leo wrote:
After reading the bug report I can only shake my head.
This is Yet Another Example of the Iron Law of Bureaucracy in action. (http://www.jerrypournelle.com/reports/jerryp/iron.html) In this case, the people running the project clearly see nothing wrong with putting their own convenience first and the needs of the (mere) users second.
On Wed, May 25, 2011 at 16:20, Mike Williams dmikewilliams@gmail.com wrote:
There are more details here: https://bugzilla.redhat.com/show_bug.cgi?id=682555
Mike
I assume that the installer now checks the amount of available memory and displays a warning screen when you attempt an install on a 512MB RAM system, no?
Or was that too considered "too disruptive"?. Disrupting the install without previous warning is too disruptive, if you ask me.
FC
On 05/26/2011 03:19 AM, Fernando Cassia wrote:
I assume that the installer now checks the amount of available memory and displays a warning screen when you attempt an install on a 512MB RAM system, no?
Or was that too considered "too disruptive"?. Disrupting the install without previous warning is too disruptive, if you ask me.
This is already answered in the bug report in part. It is not possible to predict the memory requirements in advance. It varies quite a bit depending on the configuration of the system, installation method etc. The installer team has been working on the installer for almost a decade now. Let's just say, the obvious things have already been considered.
Rahul
On Thu, 2011-05-26 at 02:57 +0530, Rahul Sundaram wrote:
- Release Notes have long lead times and are no longer suitable for
flagging important last minute changes in system requirements.
Fedora doesn't rely on only the release notes. There are other places including the common bugs page which is linked from the release announcement and other prominent places.
https://fedoraproject.org/wiki/Common_F15_bugs#Installation_requires_more_me...
Unfortunately that's not something likely to be seen by potential newbies who are thinking of trying out this Fedora thing. The fact that more than 512MB is required is a fact of life for the moment. Stating the wrong value on the primary entry point for Fedora information is a bug in the release process (now fixed).
poc
On Wed, May 25, 2011 at 2:27 PM, Rahul Sundaram metherid@gmail.com wrote:
On 05/26/2011 02:46 AM, Kam Leo wrote:
After reading the bug report I can only shake my head.
- The problem was known at least a month before the release date.
Yes. As noted in the bug report, a change in the installer and related components are going in for Fedora 16 but the amount of change was considered too disruptive by the installer team to risk pushing in a change just a month before release. Note that Fedora 15 development is already on a code freeze at that time and only important and confined bug fixes are supposed to be pushed in at that point. This bug fix won't be confined and requires significant changes in many components. Those are very risky to push through one month before the release in a installer.
- QA feels that they're powerless to flag this problem as a show stopper.
QA works against a well documented and publicized release criteria that gets frequent updates via test list
http://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
Strange that being able to install on a system with minimum hardware requirements is not part of the criteria. Or is it covered in item 5 and the team interprets it differently?
In particular, the installer in Fedora 14 already required more memory in some cases and this isn't considered a show stopper bug to block the release as per the release criteria.
There is nothing wrong with changing minimum hardware requirements. I just would like Fedora publicize the requirements earlier so I don't waste time on a the release is not compatible with my equipment.
- Release Notes have long lead times and are no longer suitable for
flagging important last minute changes in system requirements.
Fedora doesn't rely on only the release notes. There are other places including the common bugs page which is linked from the release announcement and other prominent places.
https://fedoraproject.org/wiki/Common_F15_bugs#Installation_requires_more_me...
It seems that the requirements were posted everywhere except the Release Notes and, until today, the home page.
Rahul
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
On 05/26/2011 03:50 AM, Patrick O'Callaghan wrote:
Unfortunately that's not something likely to be seen by potential newbies who are thinking of trying out this Fedora thing
I don't think we need to worry about newbies using the net installation. They aren't likely to start with that. Also the % of users using Fedora with less than 1 GB of RAM isn't that much according to Smolt stats. In addition to that, http://fedoraproject.org/get-fedora also has been updated to document this. If you have suggestions on where else to advertise, feel free to pitch in.
Rahul
On 05/26/2011 03:53 AM, Kam Leo wrote:
QA works against a well documented and publicized release criteria that gets frequent updates via test list
http://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
Strange that being able to install on a system with minimum hardware requirements is not part of the criteria. Or is it covered in item 5 and the team interprets it differently?
Just to be clear,
Item 5 is
"The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above "
Doesn't say anything about minimum hardware requirements. It has never been a blocker for any release.
It seems that the requirements were posted everywhere except the Release Notes and, until today, the home page.
Yes indeed. Not very ideal but documentation team is running low on people willing to contribute. I am sure they will welcome any help if you want to help out
Rahul
On 05/25/2011 06:24 PM, Rahul Sundaram wrote:
On 05/26/2011 03:50 AM, Patrick O'Callaghan wrote:
Unfortunately that's not something likely to be seen by potential newbies who are thinking of trying out this Fedora thing
I don't think we need to worry about newbies using the net installation. They aren't likely to start with that. Also the % of users using Fedora with less than 1 GB of RAM isn't that much according to Smolt stats. In addition to that, http://fedoraproject.org/get-fedora also has been updated to document this. If you have suggestions on where else to advertise, feel free to pitch in.
Preupgrade should know about the limitation and refuse to run the upgrade if insufficient ram exists in the system instead of waiting for the reboot where it just hangs with no explanation....
Rahul
On 05/26/2011 04:06 AM, Kevin J. Cummings wrote:
Preupgrade should know about the limitation and refuse to run the upgrade if insufficient ram exists in the system instead of waiting for the reboot where it just hangs with no explanation....
"Should know" is true in the ideal sense. However it is far from easy to determine in advance however. Even now, the amount of memory used is given as a range instead of a specific value because of these reasons. The only thing possible is to document it and the obvious place which is the download page already has been updated. I have also added this info in the common bugs page which is referenced from the announcement and in the wiki as well. I filed a bug report against the release notes as well long back and if I find time, I will take a look at updating the package. If anyone wants to help, let me know. Thanks.
Rahul
On 05/26/2011 04:06 AM, Kevin J. Cummings wrote:
Preupgrade should know about the limitation and refuse to run the upgrade if insufficient ram exists in the system instead of waiting for the reboot where it just hangs with no explanation...
One more thing. If the installation completes but fails on reboot, this is probably a different bug and should be filed separately against Preupgrade with the details. Let's not confuse the problem
Rahul
Subject: Re: Fedora 15 installer needs more than 512MB RAM Date: Thu, 26 May 2011 03:54:17 +0530
On 05/26/2011 03:50 AM, Patrick O'Callaghan wrote:
Unfortunately that's not something likely to be seen by potential newbies who are thinking of trying out this Fedora thing
I don't think we need to worry about newbies using the net installation. They aren't likely to start with that. Also the % of users using Fedora with less than 1 GB of RAM isn't that much according to Smolt stats. In addition to that, http://fedoraproject.org/get-fedora also has been updated to document this. If you have suggestions on where else to advertise, feel free to pitch in.
Rahul ------------------------
Rahul,
First of all I want to thank the whole team for their efforts. I surely appreciate not only the quality of work, but also the quality of the product. However, I had to laugh a little when I read your note. I have some units that are running various versions of Fedora with as little as 256 megs. I guess I am part of that small percentage, but thanks much for a great product!!!
Greg
On 05/26/2011 05:00 AM, Gregory P. Ennis wrote:
Rahul,
First of all I want to thank the whole team for their efforts. I surely appreciate not only the quality of work, but also the quality of the product. However, I had to laugh a little when I read your note. I have some units that are running various versions of Fedora with as little as 256 megs. I guess I am part of that small percentage, but thanks much for a great product!!!
No problem. Not sure what you were laughing about but if you are running Fedora with 256 MB RAM, you are in a minority of Fedora users. I would say, the average Fedora user has anywhere between 1 GB and 4 GB of RAM and with every release, the amount of people using systems with even more RAM keep growing. The installer used to do a number of hacks to keep the memory usage low that affected consistency and sometimes created hard to debug issues which ultimately negatively impacted users. Some of the recent changes use more RAM but makes the installer much more streamlined and makes the environment more consistent with that of the installed system. It is a trade off.
Rahul
Kevin J. Cummings:
Preupgrade should know about the limitation and refuse to run the upgrade if insufficient ram exists in the system instead of waiting for the reboot where it just hangs with no explanation....
Rahul Sundaram:
"Should know" is true in the ideal sense. However it is far from easy to determine in advance however. Even now, the amount of memory used is given as a range instead of a specific value because of these reasons. The only thing possible is to document it and the obvious place which is the download page already has been updated.
I don't really agree.
It will be known that at least some minimum is required (to do a minimal install), probably a higher minimum is required (to do one of the prepared list of packages; of which they can be assessed, having fixed numbers of packages), and it should be possible to calculate the highest minimum (kitchen sink installs). And the install routine ought to be able to do a memory count and fire up an appropriate memory warning *as* *you* *pick* which type of install to do (whether that be "insufficient memory" or "probably insufficient memory"), not simply abort ten minutes or more into churning through package lists trying to work out dependencies.
This reminds me of the crap we (users) had to go through in the 1980s, fiddling around with stack sizes, trying to get some programs to run because the programmer was crap. All we could do was experimentally keep increasing the value, trying to get one that would work, pot luck. Since we had no idea how the program worked, there was no way we could have worked out the right value.
Another thing that springs to mind: The memory requirements to install have often been higher than what was required to actually run the installed system. That smacks of bad programming, in itself.
On Thu, 2011-05-26 at 05:51 +0530, Rahul Sundaram wrote:
I would say, the average Fedora user has anywhere between 1 GB and 4 GB of RAM and with every release, the amount of people using systems with even more RAM keep growing.
Must be only the hard core users. Because it's still common to see new computers only come with 1GB, here. Never mind people who continue using old computers, where the range is more typically between 500MB and 1GB, with 1GB being considered luckily endowed.
On 05/26/2011 06:49 AM, Tim wrote:
On Thu, 2011-05-26 at 05:51 +0530, Rahul Sundaram wrote:
I would say, the average Fedora user has anywhere between 1 GB and 4 GB of RAM and with every release, the amount of people using systems with even more RAM keep growing.
Must be only the hard core users. Because it's still common to see new computers only come with 1GB, here. Never mind people who continue using old computers, where the range is more typically between 500MB and 1GB, with 1GB being considered luckily endowed.
I am talking about stats from Smolt. They don't differentiate between "hard core users" from ordinary ones. Feel free to look it yourself.
Rahul
On 05/26/2011 06:46 AM, Tim wrote:
I don't really agree.
It will be known that at least some minimum is required (to do a minimal install), probably a higher minimum is required (to do one of the prepared list of packages;
If you have patches, Anaconda has a development mailing list, IRC etc. If you have suggestions, there is bugzilla. I would recommend using those forums.
Rahul
On Wed, May 25, 2011 at 21:21, Rahul Sundaram metherid@gmail.com wrote:
No problem. Not sure what you were laughing about but if you are running Fedora with 256 MB RAM, you are in a minority of Fedora users. I would say, the average Fedora user has anywhere between 1 GB and 4 GB of RAM and with every release, the amount of people using systems with even more RAM keep growing
What kind of rocket science is needed by the average linux installer, besides extracting RPMs or .tar.gz files and copying files to the HD?
Other than selecting different kernels based on architecture (say, i386, i686, etc) after hardware sniffing, couldn´t a "working bootable system" base image be extracted from a single file, and then only customize the drivers (kernel modules) needed for a particular system?, and additional packages selected by the user?.
In other words, if I install F15 on a Atom powered Netbook, or AMD Opteron workstation, surely the result of a "minimum install" is the same. Why make the installer fiddle with dozens of RPMs then (which takes a lot of time) instead of copying a partition image of this "minium bootable system" from DVD to HD??.
Thoughts? (just thinking aloud) FC
On 05/26/2011 07:17 AM, Fernando Cassia wrote:
What kind of rocket science is needed by the average linux installer, besides extracting RPMs or .tar.gz files and copying files to the HD?
Other than selecting different kernels based on architecture (say, i386, i686, etc) after hardware sniffing, couldn´t a "working bootable system" base image be extracted from a single file, and then only customize the drivers (kernel modules) needed for a particular system?, and additional packages selected by the user?.
I think you are grossly underestimating the complexity of a modern Linux distribution installer. ISCSI, LUN storage discovery, RAID, LVM, kickstart, network handling, kdump, mirror lists, storage handling, swap, partitioning, encrypted devices, resizing, handling upgrades etc are just some of the things I remember off hand that Anaconda does. So no, not rocket science but far from trivial either.
Rahul
On Wed, May 25, 2011 at 22:51, Rahul Sundaram metherid@gmail.com wrote:
I think you are grossly underestimating the complexity of a modern Linux distribution installer. ISCSI, LUN storage discovery, RAID, LVM, kickstart, network handling, kdump, mirror lists, storage handling, swap, partitioning, encrypted devices, resizing, handling
At least 4 of your big list could be summed up as "partitioning". Many others as "hardware sniffing".
So I repeat my question: After partitioning is done, wouldn´t it be easier to copy a "base bootable image" to a volume?. Wasn´t that the big change in Windows installer from XP to 7?, the fact that the installer is much faster because it just copies/uncompresses a bootable image of the pre-installed OS, then does tweakings/settings on top of it?
FC
On 05/26/2011 07:30 AM, Fernando Cassia wrote:
So I repeat my question: After partitioning is done, wouldn´t it be easier to copy a "base bootable image" to a volume?. Wasn´t that the big change in Windows installer from XP to 7?, the fact that the installer is much faster because it just copies/uncompresses a bootable image of the pre-installed OS, then does tweakings/settings on top of it?
You probably need to redirect your question to a more appropriate one like Anaconda-devel list. I have no idea how Windows installers work. There is a difference between how live images work and the non-live installation in Fedora. In the case of live images, you are essentially copying a full image to the disk and writing a boot loader. It is extremely fast. Maybe takes 3 minutes to do the entire installation. The regular installer installs RPM packages. In the latter, you are trading off speed for a lot more flexibility (choose packages, filesystem etc). Whether it is feasible at all to copy a base image and add on top of it is not known to me.
Rahul
On Wed, May 25, 2011 at 6:21 PM, Rahul Sundaram metherid@gmail.com wrote:
On 05/26/2011 06:49 AM, Tim wrote:
On Thu, 2011-05-26 at 05:51 +0530, Rahul Sundaram wrote:
I would say, the average Fedora user has anywhere between 1 GB and 4 GB of RAM and with every release, the amount of people using systems with even more RAM keep growing.
Must be only the hard core users. Because it's still common to see new computers only come with 1GB, here. Never mind people who continue using old computers, where the range is more typically between 500MB and 1GB, with 1GB being considered luckily endowed.
I am talking about stats from Smolt. They don't differentiate between "hard core users" from ordinary ones. Feel free to look it yourself.
I create and run multiple virtual Fedora installs which are clones of each other. I do not feel it is proper to let Smolt report each instantiation because the hardware is virtual and identical. Does Fedora Project really need those virtual stats?
By the way, the smaller the memory footprint required to support a graphical environment the better it is for me; i.e. more virtual machines per box.
Rahul
On 05/25/2011 06:47 PM, Fernando Cassia wrote:
Why make the installer fiddle with dozens of RPMs then (which takes a lot of time) instead of copying a partition image of this "minium bootable system" from DVD to HD??.
Having a partition image on the DVD would make the .iso for it considerably larger for very little gain.
On 05/26/2011 07:40 AM, Kam Leo wrote:
I create and run multiple virtual Fedora installs which are clones of each other. I do not feel it is proper to let Smolt report each instantiation because the hardware is virtual and identical. Does Fedora Project really need those virtual stats?
Can't hurt to send out this info. QA team might be able to prioritize bugs based on it. Virtualization team might be able to take advantage of it in someway. We don't often know in advance how the info is going to get used.
By the way, the smaller the memory footprint required to support a graphical environment the better it is for me; i.e. more virtual machines per box.
Agreed.
Rahul
On Wed, May 25, 2011 at 23:04, Rahul Sundaram metherid@gmail.com wrote:
There is a difference between how live images work and the non-live installation in Fedora. In the case of live images, you are essentially copying a full image to the disk and writing a boot loader. It is extremely fast. Maybe takes 3 minutes to do the entire installation. The regular installer installs RPM packages.
Exactly my point. I will ask in the list you suggested. I think it´s worth exploring the live image base install and then do add-on RPMs on top of it.
FC
Kam Leo wrote:
I tried upgrading my system using the DVD, Netinstall CD, and Preupgrade. Each time boot got stuck at the line "Trying to unpack rootfs image as initramfs. . . ". It seems that the installer files have gotten fatter and more memory is required.
This is a known problem, http://fossplanet.com/f13/fedora-15-i386-netinst-iso-problems-158445/, but no one on the Fedora QA or Documentation team thought that it was material to add to the Release Notes.
Everything is getting bigger, I was trying to install RHEL6 on a 2GB firewall machine, and it failed because it couldn't configure KDUMP with 2GB of RAM. Did give me a working install, though, but I think things after KDUMP didn't get setup, big machines seem to run longer after that setup.
Think I'm going with DragonFly BSD anyway, Linux has some serious networking limitations for what I want to do.
Kam Leo wrote:
On Wed, May 25, 2011 at 12:20 PM, Mike Williamsdmikewilliams@gmail.com wrote:
On Wed, May 25, 2011 at 2:40 PM, Joe Zeffjoe@zeff.us wrote:
On 05/25/2011 10:44 AM, Kam Leo wrote:
It seems that the installer files have gotten fatter and more memory is required.
When I checked http://fedoraproject.org/ yesterday, it said that Fedora 15 required 500 MB RAM; now, it says 768. I don't know if the Release Notes have been updated yet, but it's right there on their home page.
There are more details here: https://bugzilla.redhat.com/show_bug.cgi?id=682555
Mike
After reading the bug report I can only shake my head.
- The problem was known at least a month before the release date.
true.
- QA feels that they're powerless to flag this problem as a show stopper.
Get a better grip on the impact of this issue, there are few people using that little memory on their video cards, much less main memory. And the fix seems to require changes in many places and would need code freeze exceptions. The risk to reward ratio is very high on that.
- Release Notes have long lead times and are no longer suitable for
flagging important last minute changes in system requirements.
Here I'm totally with you, with a month lead the release notes should have, and could have, been changed. If you report a bug you often get asked if you read the release notes, I think that implies they should cover stuff known a month in advance.
In any case, you have your answer.
Joe Zeff wrote:
On 05/25/2011 02:16 PM, Kam Leo wrote:
After reading the bug report I can only shake my head.
This is Yet Another Example of the Iron Law of Bureaucracy in action. (http://www.jerrypournelle.com/reports/jerryp/iron.html) In this case, the people running the project clearly see nothing wrong with putting their own convenience first and the needs of the (mere) users second.
Look, someone didn't change the Release Notes which they should have, now they have. You had an install fail, nobody died, the Earth's magnetic field didn't flip, and if you want to bitch about something the users didn't need or want, start with GNOME3!
On 05/26/2011 04:54 PM, Bill Davidsen wrote:
Look, someone didn't change the Release Notes which they should have, now they have. You had an install fail, nobody died, the Earth's magnetic field didn't flip, and if you want to bitch about something the users didn't need or want, start with GNOME3!
I know you're frustrated, but don't take it out on me. I'm not the one complaining, I haven't (yet) upgraded to F 15 and I've already migrated from Gnome to XFCE to avoid Gnome 3. All I did was point out that projects tend to get less and less responsive to users because they end up getting controlled by people who are more interested in that control than in the project itself.
On 05/27/2011 05:52 AM, Joe Zeff wrote:
I know you're frustrated, but don't take it out on me. I'm not the one complaining, I haven't (yet) upgraded to F 15 and I've already migrated from Gnome to XFCE to avoid Gnome 3. All I did was point out that projects tend to get less and less responsive to users because they end up getting controlled by people who are more interested in that control than in the project itself.
You made a assumption (or a accusation if you will) on the entire project with a diverse base of contributors that it was about control or convenience of developers and not users and asserting it would only demotivate people who work hard to help users (unless one believes there aren't any). I don't quite see the benefit of this. A reasonable discourse would be be start off from a position of good will and either provide suggestions or help our directly. It is possible and even very much likely that mistakes would be routinely made but the approach towards resolving them is going to look different.
Rahul
On 05/26/2011 05:32 PM, Rahul Sundaram wrote:
You made a assumption (or a accusation if you will) on the entire project with a diverse base of contributors that it was about control or convenience of developers and not users and asserting it would only demotivate people who work hard to help users (unless one believes there aren't any).
At this point, I've turned my back on Gnome because it's gone in a direction that repels me and I've learned from experience that the devs don't care and the users are afraid of them. I offered an observation based on what I'd seen and you found it offensive, so I shan't be contributing to this thread any longer because I prefer not to offend others without good reason.
As far as Gnome 3 is concerned, you can get a good idea of my current attitude by remembering Rhett Butler's last comment to Scarlett at the end of Gone With The Wind.
On 05/27/2011 06:15 AM, Joe Zeff wrote:
On 05/26/2011 05:32 PM, Rahul Sundaram wrote:
You made a assumption (or a accusation if you will) on the entire project with a diverse base of contributors that it was about control or convenience of developers and not users and asserting it would only demotivate people who work hard to help users (unless one believes there aren't any).
At this point, I've turned my back on Gnome because it's gone in a direction that repels me and I've learned from experience that the devs don't care and the users are afraid of them. I offered an observation based on what I'd seen and you found it offensive, so I shan't be contributing to this thread any longer because I prefer not to offend others without good reason.
Earlier I found it needlessly aggressive. Now I am just very puzzled. This thread wasn't about GNOME at all as even a cursory reading of the subject line would show. I am wondering why you think it is.
Care to explain?
Rahul
On 05/26/2011 05:46 PM, Rahul Sundaram wrote:
I am wondering why you think it is.
Care to explain?
I was using Gnome as an example of how project devs turn their backs on the needs of the users. The same thing seems to be happening, gradually, with the Fedora devs, at least to the extent of not managing to keep such vital things as minimum memory requirements up to date. I was pointing out that such a big project tends to become a bureaucracy simply because it's almost impossible to control otherwise, and the dedicated bureaucrats always end up in charge and those who actually care about the project itself get pushed to the side, if they're lucky.
On 05/27/2011 06:34 AM, Joe Zeff wrote:
I was using Gnome as an example of how project devs turn their backs on the needs of the users. The same thing seems to be happening, gradually, with the Fedora devs, at least to the extent of not managing to keep such vital things as minimum memory requirements up to date. I was pointing out that such a big project tends to become a bureaucracy simply because it's almost impossible to control otherwise, and the dedicated bureaucrats always end up in charge and those who actually care about the project itself get pushed to the side, if they're lucky.
[Not related to just you but I am going to make a general point here]
As a general over-simplification and generalization of a complex subject, it seems appealing however the specific case doesn't support your assumptions and manages to insult contributors from two different projects in one go. To claim, this specific instance was a example or proof that it was all about convenience of developers requires more evidence or atleast an attempt to have a conversation rather than a mere drive by assertion. It adds no value to the discussion whatsoever and derails a pointed conversation. If I may, I would recommend you avoid doing this because I really don't see any benefit in doing so and can immediately point out several negative factors. If you don't like the decision not to put in a bunch of intrusive patches in the installer a month before release, you are free to say so and I have explained the nature of the decision to help make a more informed opinion on this and some people seem convinced and others have still disagreed which is fine. If you don't like the design of particular aspects of GNOME Shell, I would readily agree that you may very well have a point but questioning the motivations of contributors is not needed or warranted IMO. Being a good critique involves a good understanding of the subject matter, considerations of both sides, assumption of good will and being specific. Most importantly, stick to technical discussions instead of making it personal. Let it be about the handling of the bugs instead of about how the developers are careless or whatever. Even assuming some of them are, this approach just wouldn't yield any good results.
Rahul
On 05/26/2011 06:18 PM, Rahul Sundaram wrote:
As a general over-simplification and generalization of a complex subject, it seems appealing however the specific case doesn't support your assumptions and manages to insult contributors from two different projects in one go.
I didn't intend to offend you, or for that matter anybody else. I was just stating what I considered to be a fact of how the world works. Alas, you seem to have taken it personally for reasons I don't understand. For that I apologize.
This will be my last word on the subject unless something forces me to respond.