Re: [PHILOSOPHY] Stability and Release Schedules
- From: Jim Cornette <fc-cornette@xxxxxxxxxxxxxx>
- Date: Fri, 28 Apr 2006 23:40:47 -0400
Rickey Moore wrote:
On Thu, 2006-04-27 at 22:40 -0400, Jim Cornette wrote:John Wendel wrote:
I'm for a stable base to allow for a more free flowing progression of all the many packages involved and a distribution that tracks upstream as closely as possible.
I'm sure there are pros and cons for both scenarios.
I've advocated something similar, where for a several week period,
certain groups of packages are upgraded with time for the users to
bugtest and report what happened to their installations as a result.
Once the noise level drops, get hit with the next group of packages.
Everyone would be on the same page, the developers could focus on just
those issues and progress along with the users. When the test period is
over the proven stable packages would be in the updated system image.
One could burn CD's that contained a stable system. Those who enjoy
cutting edge would 'upgrade' regularly via a yum script for the next set
of installs packages. It's a thought. Those who just want a running
stable system need not apply to the scheme, and just wait until yum
updates to newer proven-stable packages. It's a thought. Ric
It sounds like concentration on issues and a smaller area of focus would be captured with this concept. I do think that putting a time limitation on the phased update release would rush developers as well as those testing the updates for problems. Also some developers are dedicated to networking, kernel, graphical interface, cli applications, security issues, Internet applications and the like. They would still have to keep on developing their components and hopefully not be backtracked by the phased in updates exposing bugs.
On the plus side, these developers can apply any needed changes exposed by the phased update results. If regression is needed on the phased update, development should be on track. If major or minor base system components need revising to progress the phase of updates, the whole lot of currently being developed packages that depend on components needing changes has to be implemented.
The quality control should be higher with the two week limited component updates. That is if reduced amount of released components is traceable to the problem. Quality might suffer though if the bug is illusive because it exposed a bug that was not exposed earlier by the changes.
With the different ideas regarding update cycles, progressive releases, snapshot to snapshot and pruned systems from periodic fresh installs of resulting snapshots, we can move forward with a better upgrading cycle.
Personally, I like progressive development and a sort of safety net for testing the updates for a few weeks as you suggested. I believe the testing repository is setup for this reason.
Is it possible that software is not like anything else, that it is meant to
be discarded: that the whole point is to always see it as a soap bubble?
fedora-list mailing list
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
- Prev by Date: Re: Annoying win key problem
- Next by Date: On passwords, securtiy and real -sweat, blook and tears- life
- Previous by thread: Re: [PHILOSOPHY] Stability and Release Schedules
- Next by thread: Re: [PHILOSOPHY] Stability and Release Schedules