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 addition.
(and yes, I consider it bad that users have to search for a weird buildservice repository that is not even in the default list to get the latest version of e.g. digikam).
Agree.
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 guess. I very much prefer to try to do it, and see what we can achieve. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org