On 01/27/2013 08:00 PM, Ranjan Maitra wrote:
On Mon, 28 Jan 2013 10:55:24 +1100 Philip Rhoades phil@pricom.com.au wrote:
People,
Date: Sun, 27 Jan 2013 15:18:40 -0500 From: "Eddie G. O'Connor Jr." eoconnor25@gmail.com To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: humble suggestion to Fedora developers Message-ID: 51058BA0.8020509@GMail.com Content-Type: text/plain; charset=UTF-8; format=flowed
On 01/23/2013 02:59 PM, James Freer wrote:
On Wed, Jan 23, 2013 at 7:34 PM, Joe Zeff joe@zeff.us wrote:
On 01/23/2013 06:53 AM, Reindl Harald wrote:
because first new anaconda was approved and integration all over the distribution started and after that damage was done people realized "hm new anaconda is not ready"
So what you're saying is, it was approved before it was ready. Judging from what else you wrote, the devs didn't realize it when they approved it. This suggests to me that approval came too early in the process, before proper testing was done and that important parts of the program hadn't been completed. If so, is there anything that can be done to prevent this from happening yet again?
I have the greatest respect for the developer's that put in considerable effort for each release. The problem with 6 month release cycle is too little time. I've used linux now for almost 6 years with Ubuntu and Fedora. Some distros use a two year release which is too long. One or two use an annual release which i think is about right... development and testing can fully take place. Why not consider an annual release which would give appropriate time for all to take place?
james
I would have to agree with you James, it might not be a bad idea for them to stretch their release time out a bit? I would have positives from all sides. First,....the developers would be able to REALLY put their apps and what-not through a GRUELING testing session, this way...when they say it works.....IT WORKS! Second,.....the public wouldn't find themselves scurrying to acquire the latest version, and slamming it onto their machines without knowing that things won't crash & burn un-necessarily......also it would give the public time to "adapt" and become comfortable with the latest release, instead of going into shock at the arrival of a new desktop environment...or new feature-sets that were not there before. I guess it's just a matter of someone (or a LOT of someone's) voicing their opinion loud enough to be heard by the higher-ups? I don't know that they would actually change things around like that....(it would be NICE!) but eventually they might get restless enough to completely flip thing around and have longer time frames between releases.
Maybe we should try out, say, a nine month cycle and if it doesn't suit
- go back to six months? I am conscious though of the human tendency to
put off things when there is more time to get them done . .
But the rush to release will still be there, whether it is a 6- or 9- or 12-month cycle? At the point of release, inadequately-tested new features may still be a problem, no?
I think a more reliable approach is to have a rolling release model, with periodic snapshot RPMs in a cycle? The periodic snapshots could be benchmark-based, so no specific time schedule, rather than calendar-based?
Ranjan
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
Now THIS sounds feasible, and it would make for a smoother transition from one release to the next! I wonder whom I would have to speak to.....to see if this could be done? Or is it a group thing?.....would I direct something like this towards the kernel maintainers?....the admins?.....who would get "the call"?...
EGO II