Mailinglist Archive: opensuse-factory (393 mails)

< Previous Next >
Re: [opensuse-factory] OpenSUSE, bugs and some considerations
  • From: James Tremblay <jamesat@xxxxxxxxxxx>
  • Date: Mon, 5 Mar 2007 10:51:09 -0500
  • Message-id: <200703051051.10152.jamesat@xxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
References