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.
Jim
--
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?
