Mailinglist Archive: opensuse-project (422 mails)
|< Previous||Next >|
Re: [opensuse-project] Announcing openSUSE Tumbleweed project
- From: Adrian Schröter <adrian@xxxxxxx>
- Date: Mon, 06 Dec 2010 11:55:17 +0100
- Message-id: <20101206105517.8147F3C539A9@xxxxxxxxxxxx>
first of all, thanks a lot for fetching this task. If this project
succeeds, it can definitive make a difference for openSUSE :)
On Tuesday 30 November 2010 09:11:04 Greg KH wrote:
Q: How does this differ from Factory and the recently announced
A: Factory always contains the bleeding edge versions of our packages
that the maintainers have created. Sometimes these packages don't
work well together and cause the machine to fail to boot (Hence the
need for Factory-Tested). Tumbleweed will contain "stable" versions
of these latest packages that have been deemed to "work" properly.
A good example of how Tumbleweed is different from Factory would be
to look at the kernel package today in Factory. It is 2.6.37-rc as
the goal is to have the final 2.6.37 release in the next 11.4
release. But, it is still under active development and not
recommended for some people who don't like reporting kernel bugs.
For this reason, Tumbleweed would track the stable kernel releases,
in this case, it would stay at 2.6.36 until the upstream kernel is
released in a "stable" format.
Even though .37 is final, there are still often regressions (esp. due to
driver updates). I think some Tumbleweed:Candidate project would be the
requirement in any case.
Just a suggestion:
We may can add a voting in OBS, where people can say "works for me" or "breaks
heavily for me + bugnumber". The Tumbleweed maintainer can decide afterwards,
if it is worth to ignore the problems (there will be always some).
And this would ensure that a sufficient number of people have tested the
update. (I think base components would require more people to test than leaf
Q: What types of packages would be updated in Tumbleweed?
A: What do you want to see updated? Seriously, this is something that
anyone can request their packages to be updated. We will rely on the
maintainers of the packages to be the ones determining the "stable"
versions to be pushed into Tumbleweed.
This can help with projects that don't always line up their release
dates with existing openSUSE releases. If (for example) GNOME 3.0
comes out and is deemed "stable" 1 month after a openSUSE happens,
users would not have to wait 6 more months to use it in a semi-stable
Again, I think there must be some more detailed policies. I agree that your
example with Gnome 3.0 works out if it is really a seperate component. And
this is not that easy to decide. But I can tell from our old time experiences,
when we had the "supplementary" stream for released distributions (which is
more or less what Tumbleweed is now) that even patch level updates of Gnome
destroyed very often other components (not limited to KDE also server related
packages like apache). I wasted a lot of time in fixing these issues and it
was one of the major reasons why we introduced the project model in OBS.
Problem here is that the testers checked if Gnome is working (if at all), but
ignored all the other users.
So we either need to limit us here or really to have a working test setup
which is powerfull enough for such big updates, IMHO.
Q: But wait, can't you do this today on your own by just adding a bunch
of different repos to zypper and relying on that?
A: Yes, you can, but if my zypper repo list is any example, that gets
unwieldy (I seem to average about 12 per machine), and we don't want
to have every user be forced to do this on their own. Tumbleweed
would provide a single place for users that want to be on the
semi-bleeding edge of packages, to have it all in one place.
IMHO the number of repos is not the issue in first place, there could be other
solutions for it like supporting the .nu files.
More important to my mind is to build up a common policy for all packages in
this project, including a defined QA.
Fore sure we will make mistakes and we will learn. But need to learn together
based on this policy to my opinion.
SUSE Linux Products GmbH
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx
|< Previous||Next >|