On Thu, Jun 14, 2012 at 11:31:13PM +0200, Obexer Christoph wrote:
Am Donnerstag, 14. Juni 2012, 10:46:32 schrieb Stephan
Let's discuss things very openly - I think
we learned enough about where
the current model works and where it doesn't so we can develop a new one
I'm one of those unwanted posters that could become a contributor but won't
the warm welcome on this list as somebody else already pointed out in another part of
A while ago i filed a request for just this improvement in /dev/null err
i basically got no attention, so i planned to post here after the 12.2 release - you were
faster and i would have been flamed / ignored anyway^^
This is a process change, not a distribution feature... So what we are discussing here.
I've seen a few openSuSE releases from the
Factory perspective (being here since the KDE4.0 release) and the failure pattern for
Factory was always the same:
1) nobody uses Factory
2) nobody cares for Factory
* feature freeze comes close
3) rush in unstable packages to catch the next release with the wanted version
* as a Factory user you should skip the next 1 or 2 milestones because they are horrible
* a few people in the community fix up some of the bugs (and start to look at BNC)
5) RC1, better but still not up to where it should be
6) time based release have to go out, "we fix that with an update"
my proposal is - as noted in the Fate entry:
do it tumbleweed style, that is a package goes into release(Tumbleweed) when its stable
and has been tested, if it breaks something -> revert
since Tumbleweed is always stable just release openSuSE $VERSION on time by copying
Tumbleweed into a release repo
You will never be able to do:
- compiler upgrades
- other toolchain upgrades like libtool, automake, autoconf ... all of whiuch usually
break their share of packages
- gnome, kde changes that break non-core-gnome/kde apps
- perl upgrades, python upgrades, etc.
all of these happen in Factory and will not be possible with your model.
New toolchain things _BREAK_ other stuff ... either by incompatibility or bitrotting. It
needs to be fixed.
doing this the right way would make openSuSE a whole
lot more stable IMHO, and it would also attract more contributors,
See above, it would basically turn us to an effective stand still.
because getting something in the hands of actual users
could be done as a weekend project, instead of a multiple month time investment
i could go into more detail, but I'm unwanted here so i try to keep it short
I the hope this is being well received and it might improve openSuSE
A bit more rolling upgrades like Tumbleweed would be possible ... But again, chaning
is not possible in your model I think.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org