Hello all,
I read the last 89 entries at one sitting and I have formulated an opinion 
that I have sort of posted b4.

I think a radicle change to release theory should be entertained.
I think that since 10.2 was a December release we had the opportunity to 
change to an annual release cycle. With this change we could .
have both repository and bugzilla quarterly change cycle. I.E.
January:
   10.3 ao: would be a new repository with 10.2 code and it's goal would be 
just to include bugfixes found in the first three months of 10.2.. nothing 
else, using this repo as a repair location for things like the current ZMD 
issue, this could be an "edge" update channel with scripts\rpm's to effect 
repairs. sort of an annual remastering.

April:
  10.3 a1: move code with bugfixes in the first quarter and include program 
updates that have been voted on as stabilized in the build service during the 
the first half of year

July:
   10.3 b0:  move code with  bugfixes from second quarter\first half. as well 
as mods to first half program updates as stabilized by the buildservice.
Announce all testing requirements and start all testing.

September:
  10.3 b1:  move code w\updates  begin code freezing processes.

December:
   10.3 final: Move frozen code to release repo.

This would stabilize peoples expectations as to when they will need to start 
testing and give a full 5 months to stabilize(release could be 12\20 every 
year! Happy Holiday
)
 This would as a minor side effect slow down the adoption of "cutting edge" 
packages and technologies but also give the whole linux community time to 
create stability in those packages before OpenSUSE uses them officially. 
Consider that the buildservice would handle most of the testing and 
stabilizing work on the cutting edge, not the factory. i.e. kde4\gnome 2.x 
Most importantly any update service changes could be Add-ons!

I think it is important to state that the Buildservice is an entity of it's 
own, with the responsibility of generating packages suitable for the main 
distro, therefor having the main distro slow down isn't a bad thing.
The main distro factory should only concern itself with functionality updates 
and YAST expansion. i.e. printer discovery and more Yast modules like one for  
building a proxy server and adding a filtering service or expanding the 
choices in the DHCP config module.
The BS should be the place where all community and cutting edge work gets done 
in a download it at your own risk "add-on" fashion, taking the risk out of 
using the main distro.
This would likely reduce the cost of including the 18 months of security 
patches to OpenSuSE  and 5 years support to SLED by minimizing the base 
distro changes. 
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to