Hi Greg, 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 Factory-Tested? 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 packages).
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 form.
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. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org