On 01/27/2013 08:00 PM, Ranjan Maitra wrote:
On Mon, 28 Jan 2013 10:55:24 +1100 Philip Rhoades <phil@xxxxxxxxxxxxx>
wrote:
People,
Date: Sun, 27 Jan 2013 15:18:40 -0500
From: "Eddie G. O'Connor Jr." <eoconnor25@xxxxxxxxx>
To: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: humble suggestion to Fedora developers
Message-ID: <51058BA0.8020509@xxxxxxxxx>
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@xxxxxxx> 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
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
