Mailinglist Archive: opensuse-project (422 mails)

< Previous Next >
Re: [opensuse-project] Announcing openSUSE Tumbleweed project
  • From: Vincent Untz <vuntz@xxxxxxxxxxxx>
  • Date: Thu, 2 Dec 2010 10:16:19 +0100
  • Message-id: <20101202091619.GA2016@xxxxxxxxx>
Le jeudi 02 décembre 2010, à 09:12 +0100, Dirk Müller a écrit :
On Wednesday 01 December 2010, Vincent Untz wrote:

One other thing I'm worried about is that this might result in some
contributors focusing on the rolling update, and some others focusing on
the "usual" release. Ideally, people would work together, and on both,
but that's "ideally", and things will be different. So that literally
splits our effort.

I don't see why the efforts have to be splitted? If its a leaf package or
something where we can know that it is stable and compatible, you can release
a maintenance update for openSUSE. This process is open and already in use,
and you get the good security watching from the SUSE Security Team in

(and yes, I consider it bad that users have to search for a weird
repository that is not even in the default list to get the latest version of
e.g. digikam).


openSUSE Updates do not have a strict version freeze.

My understanding was that we're fine releasing an update if it fixes an
important bug that affects our users. Are we really okay pushing 100+
updates when a new GNOME from the same branch is out, without first
checking if the changes are really important? Are we fine releasing an
update to tracker every 2 weeks (for a while, tracker 0.8.x had a new
upstream version every 2 weeks)? That's something we would do for
Tumbleweed, but unless things changed, that's not what our current
policy for regular releases.

And I can really find examples where this would still split the effort.
Again, just taking the example of GNOME:
openSUSE 11.1: GNOME 2.24
openSUSE 11.2: GNOME 2.28
So during the development of 11.2, if we had had Tumbleweed, we would
have had to maintain 2.24.x in 11.1, 2.26.x in Tumbleweed and 2.27.x in
11.2/Factory at some point. Sure, in such a case, a solution would be to
skip 2.26.x, but users wouldn't be happy.

Anyway, we're getting nowhere here and my answers just look like stop
energy, which is something I don't like :-) My point is that we should
be careful to not split our efforts when there'll be a risk. I'll make
my point if/when this will happen -- making it now doesn't help, I

I very much prefer to try to do it, and see what we can achieve.


Les gens heureux ne sont pas pressés.
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >