On 2 March 2013 11:03, Lars Marowsky-Bree
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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org