Mailinglist Archive: opensuse-factory (689 mails)

< Previous Next >
Re: [opensuse-factory] Tumbleweed, future directions
On 2 March 2013 11:03, Lars Marowsky-Bree <lmb@xxxxxxxx> wrote:
The only "issue" I keep having for the first one to three weeks of a new
openSUSE + Tumbleweed rebase (and about which we just don't agree) is
that it doesn't always happen when it's convenient for me to rebase my
laptop, and that I want to keep history around for a few days so I can
bisect/compare if needed. But I decided to make myself unpopular with
the OBS team and help myself this time ;-)
(home:LarsMB:Tumbleweed-12.2)

I would also say this is the biggest 'complaint' I've heard from our
Tumbleweed users throughout the community. I understand how it came to
be, but the rebase is certainly a pain point which is a source of some
frustration to users

While I think Tumbleweed is a great project and love the fact we have
users to love it, I personally, I have an issue with Tumbleweed as I
feel it's current approach isn't well aligned with the development of
the main distribution.

I think that a number of people who would previously be testers are
now drawn to Tumbleweed, rather than testing Factory - I speak from
experience, as my original interest in Factory was born out of a
desire for the latest and greatest, and it's through that use of
Factory that I ended up the contributor to the project I am today.

Tumbleweed addresses the issue with stability when using Factory, but
I think goes too far by basing itself on released versions, and I
believe we end up with the worst of both worlds, not the best.

To illustrate, when users report bugs in Tumbleweed, I fear there is a
tendency to assume it's an issue with Tumbleweed, and therefore bugs
which are also present in the main distribution are left unfixed.

Worse than that, because of Tumbleweeds nature, being based on
released openSUSE versions, when bugs do crop up, we have the whole
maintenance process which, while makes perfect sense for a stable
distribution like openSUSE, I fear is a needless extra step for a
rolling release like Tumbleweed, and makes it more work to get
Tumbleweed fixes into Factory, when in fact quite often they're more
relevant to Factory than anywhere else.

Ideally, I'd like to see Tumbleweed evolve into something like a
'factory-stable', cherry picking Factory so users can benefit from the
new versions on a stable, but rolling, platform, while still feeding
in any bugs or suggestions into the Factory development process, and
ultimately help make the whole distribution better, rather than
something else tacked on it's side.

As Factory is a rolling release, issues like the rebase would
disappear, but there are some issues that would need to be addressed.

The biggest one that leaps out is the issue of Tumbleweed sometimes
wanting newer versions of packages than we can put in Factory because
of Factory's current focus as 'the next release version'..

However, we already hit this issue during the freezes, so we end up
the end of any release process with Factory rolling on and
'almost-released' versions being populated with select copies of stuff
from Factory

I think this approach has worked out very well for 12.3, and maybe
that is the answer for Tumbleweed? Redefine Tumbleweed as
factory-stable, with it's packages a snapshot/selection from factory,
chosen using the same approach as Tumbleweed today.

To avoid the issue where new versions of packages can't be accepted
into factory, perhaps we instead do that 'near-release' and Factory
split a little earlier, at the stabilization freeze, so Factory can
always be 'the place for new versions', Tumbleweed can select from
that what it wants based on its use case, and the select fixes or
exceptional version changes can be copied from factory to the
'near-release' version, just as we've been doing for the last few
weeks

I'm sure I'm missing something here, or does this idea have legs?

- Rich
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References