[PHILOSOPHY] Stability and Release Schedules

[Jim Cornette]

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?