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: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Il giorno lun, 05/03/2007 alle 10.51 -0500, James Tremblay ha scritto:

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.

I think an annual release cycle is too long. Linux and related applications change fast and a long release cycle risks to make users unhappy. If the release cycle is made longer, the release of updated applications through an official channel (not additional repositories or OBS) becomes necessary. If not done, we risk to have an obsolete distribution soon. In my opinion, if we want a stable distribution, the use of the build service or of additional repository should be considered an occasional event for the common user, to get only what is not / can't be provided in the distribution. Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org