On Mon, 28 Jan 2013 10:55:24 +1100 Philip Rhoades
<phil(a)pricom.com.au>
wrote:
> People,
>
>
>> Date: Sun, 27 Jan 2013 15:18:40 -0500
>> From: "Eddie G. O'Connor Jr." <eoconnor25(a)gmail.com>
>> To: Community support for Fedora users <users(a)lists.fedoraproject.org>
>> Subject: Re: humble suggestion to Fedora developers
>> Message-ID: <51058BA0.8020509(a)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(a)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