Re: [PHILOSOPHY] Stability and Release Schedules

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:

Relevant Pages

  • Re: [kde] All KNotes gone
    ... obsolete packages like knotes, ... When it spits out the proposed updates, I examine any USE flag changes ... Sometimes it involves running epc (a stub for emerge --changelog ... For core packages like portage or systemd, ...
  • Re: branding debian releases
    ... those distros is to help the developers do what needs to be done to get ... packages into good shape and get releases out. ... and also distros like `server' and `workstation' and so on?" ... Install them. ...
  • Re: Fedora 9 will not update
    ... And since there are updates for the two packages you queried, ... sure you've got the latest Yum. ... No Presto metadata available for fedora ...
  • Re: how to jigdo download a fedora 8 re-spin in one easy step?
    ... One stinkin' bleep or bloop in the process and the DVD is an ... that I insert the CD and it would install packages, ... FedoraUnity re-spin DVDis the updated packages as of Dec 18, ... If there have been, for your installation, 50 updates ...
  • Re: A great new tool for progress developers !!!
    ... > - Manage Progress applications, ... > IcePRO environment to know the time ... > - Create deployment packages ...