[opensuse-project] Announcing openSUSE Tumbleweed project
Hi all, There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences. So the time now is to stop talking about it, and actually trying to do it :) So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use. To help clear up any questions about this, here are some answers to ones that I have heard a lot recently when discussing this: 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. 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. 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. I'd like to do this "for real" after 11.4 is out, just due to the amount of time it will take to get the workflow down properly, and due to some other time constraints on my plate at the moment. I anticipate trying this out to start with based on 11.3 but I don't guarantee it all working properly right at the moment. So, any thoughts, ideas, objections? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi all,
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences.
So the time now is to stop talking about it, and actually trying to do it :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use.
<snip>
I'd like to do this "for real" after 11.4 is out, just due to the amount of time it will take to get the workflow down properly, and due to some other time constraints on my plate at the moment. I anticipate trying this out to start with based on 11.3 but I don't guarantee it all working properly right at the moment.
So, any thoughts, ideas, objections?
How would this sit in relation to repos like Packman? Would it supersede (or provide a base for) those efforts? David -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Nov 30, 2010 at 05:25:52PM -0000, Administrator wrote:
Hi all,
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences.
So the time now is to stop talking about it, and actually trying to do it :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use.
<snip>
I'd like to do this "for real" after 11.4 is out, just due to the amount of time it will take to get the workflow down properly, and due to some other time constraints on my plate at the moment. I anticipate trying this out to start with based on 11.3 but I don't guarantee it all working properly right at the moment.
So, any thoughts, ideas, objections?
How would this sit in relation to repos like Packman? Would it supersede (or provide a base for) those efforts?
Stuff in Packman is there because of legal reasons it can't be hosted in the openSUSE build system, right? Because of that, I don't see how Tumbleweed could "supersede" those packages, but it could be a base for a Packman repo for these packages to be built against. But, if there are packages in Packman that people just use because they are "more up to date" than the existing "stable" release, then yes, I could see Tumbleweed superseding it. Hope this helps explain things. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Nov 30, 2010 at 12:32 PM, Greg KH <gregkh@suse.de> wrote:
On Tue, Nov 30, 2010 at 05:25:52PM -0000, Administrator wrote:
Hi all,
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences.
So the time now is to stop talking about it, and actually trying to do it :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use.
<snip>
I'd like to do this "for real" after 11.4 is out, just due to the amount of time it will take to get the workflow down properly, and due to some other time constraints on my plate at the moment. I anticipate trying this out to start with based on 11.3 but I don't guarantee it all working properly right at the moment.
So, any thoughts, ideas, objections?
How would this sit in relation to repos like Packman? Would it supersede (or provide a base for) those efforts?
Stuff in Packman is there because of legal reasons it can't be hosted in the openSUSE build system, right? Because of that, I don't see how Tumbleweed could "supersede" those packages, but it could be a base for a Packman repo for these packages to be built against.
But, if there are packages in Packman that people just use because they are "more up to date" than the existing "stable" release, then yes, I could see Tumbleweed superseding it.
Hope this helps explain things.
thanks,
greg k-h
Packman has both newer releases of stuff in the main distro repos, and legally incumbered stuff. I assume the non-encumbered stuff will move to tumbleweed. But I worry about stuff like the broadcomm STA driver. (I think that's the one). It is typically not in any official repo during the factory time frame, and then appears in Packman shortly before or after the main release. ie. Packman does not currently support factory at all I don't believe. Without Packman support for at least some of the key kmod's and codecs needed by tumbleweed, I seriously doubt it will get much end-user adoption. So getting that buy-in is the first thing I would look to from a strategic view. Without it, I think the whole plan falls apart. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Nov 30, 2010 at 02:45:20PM -0500, Greg Freemyer wrote:
On Tue, Nov 30, 2010 at 12:32 PM, Greg KH <gregkh@suse.de> wrote:
On Tue, Nov 30, 2010 at 05:25:52PM -0000, Administrator wrote:
Hi all,
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences.
So the time now is to stop talking about it, and actually trying to do it :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use.
<snip>
I'd like to do this "for real" after 11.4 is out, just due to the amount of time it will take to get the workflow down properly, and due to some other time constraints on my plate at the moment. I anticipate trying this out to start with based on 11.3 but I don't guarantee it all working properly right at the moment.
So, any thoughts, ideas, objections?
How would this sit in relation to repos like Packman? Would it supersede (or provide a base for) those efforts?
Stuff in Packman is there because of legal reasons it can't be hosted in the openSUSE build system, right? Because of that, I don't see how Tumbleweed could "supersede" those packages, but it could be a base for a Packman repo for these packages to be built against.
But, if there are packages in Packman that people just use because they are "more up to date" than the existing "stable" release, then yes, I could see Tumbleweed superseding it.
Hope this helps explain things.
thanks,
greg k-h
Packman has both newer releases of stuff in the main distro repos, and legally incumbered stuff.
I assume the non-encumbered stuff will move to tumbleweed.
But I worry about stuff like the broadcomm STA driver. (I think that's the one). It is typically not in any official repo during the factory time frame, and then appears in Packman shortly before or after the main release.
If it's closed source, I honestly don't care at all about it. If it's open, why isn't in the main repo or in the main kernel.org tree already?
Without Packman support for at least some of the key kmod's and codecs needed by tumbleweed, I seriously doubt it will get much end-user adoption.
I don't care about closed source kernel modules that violate my personal copyright, and neither should you.
So getting that buy-in is the first thing I would look to from a strategic view. Without it, I think the whole plan falls apart.
I totally disagree, you are saying the whole reason a distro works at all is due to closed kernel modules and codecs? I seriously doubt that. I don't think it will be very hard to get Packman (or any other repo) that handles the codes up and working on Tumbleweed. Same goes for the kernel modules, if you really care about them and are willing to assume the legal liablity for them. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi there; On Tue, Nov 30, 2010 at 10:26 PM, Greg KH <gregkh@suse.de> wrote: [skipping legal mambo jambo, possibly disagreed part]
I don't think it will be very hard to get Packman (or any other repo) that handles the codes up and working on Tumbleweed.
If we can get Packman to support this as a repository that would be the most ideal solution. Nothing fancy, just need a handful of people helping Packman project. Regards, ismail -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Nov 30, 2010 at 10:37:01PM +0200, İsmail Dönmez wrote:
Hi there;
On Tue, Nov 30, 2010 at 10:26 PM, Greg KH <gregkh@suse.de> wrote:
[skipping legal mambo jambo, possibly disagreed part]
I don't think it will be very hard to get Packman (or any other repo) that handles the codes up and working on Tumbleweed.
If we can get Packman to support this as a repository that would be the most ideal solution. Nothing fancy, just need a handful of people helping Packman project.
This is probably getting off-topic here, but is there a pointer to how someone can help out the packman project to set up something like this? I see their general "send us email" from the front page, is that all, or do they need something else for something as small as this would entail? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
* Greg KH <gregkh@suse.de> [2010-11-30 21:53]:
On Tue, Nov 30, 2010 at 10:37:01PM +0200, İsmail Dönmez wrote:
Hi there;
On Tue, Nov 30, 2010 at 10:26 PM, Greg KH <gregkh@suse.de> wrote:
[skipping legal mambo jambo, possibly disagreed part]
I don't think it will be very hard to get Packman (or any other repo) that handles the codes up and working on Tumbleweed.
If we can get Packman to support this as a repository that would be the most ideal solution. Nothing fancy, just need a handful of people helping Packman project.
This is probably getting off-topic here, but is there a pointer to how someone can help out the packman project to set up something like this? I see their general "send us email" from the front page, is that all, or do they need something else for something as small as this would entail?
Posting to packman@links2linux.de should be appropriate. The reason why Packman does not build against Factory is, as I understand it, that continuous rebuilds would put too much load on the build system and that would probably apply to your proposed project as well. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2010-11-30 22:31:15 (+0100), Guido Berhoerster <gber@opensuse.org> wrote:
* Greg KH <gregkh@suse.de> [2010-11-30 21:53]:
On Tue, Nov 30, 2010 at 10:37:01PM +0200, İsmail Dönmez wrote:
On Tue, Nov 30, 2010 at 10:26 PM, Greg KH <gregkh@suse.de> wrote: [skipping legal mambo jambo, possibly disagreed part]
(but on a side note, Greg, please stop assuming we package illegal stuff)
I don't think it will be very hard to get Packman (or any other repo) that handles the codes up and working on Tumbleweed.
If we can get Packman to support this as a repository that would be the most ideal solution. Nothing fancy, just need a handful of people helping Packman project.
This is probably getting off-topic here, but is there a pointer to how someone can help out the packman project to set up something like this? I see their general "send us email" from the front page, is that all, or do they need something else for something as small as this would entail?
Helping us out can be done in a few ways: * maintaining packages: help is always welcome there, especially for more experienced packagers, * provide us with build servers: just requires running a single init script to be an OBS build slave -- but we will only do so with people we know, as being root on such a build host gives the ability to crack packages and include trojan horses or other malware in them
Posting to packman@links2linux.de should be appropriate.
Correct, anyone can get in touch with us on the mailing-list Guide cited above (no registration needed), or on IRC (on Freenode, #packman).
The reason why Packman does not build against Factory is, as I understand it, that continuous rebuilds would put too much load on the build system and that would probably apply to your proposed project as well.
Actually we *do* build against Factory (*snapshot*). Indeed, continuous rebuilds would kill our infrastructure, as we don't have that much build power (we do have a few servers though, thanks to the support of a very few individuals, and thanks to a sponsor). To be precise, we build a subset of our packages for Factory (and even for SLE11SP1), typically those that you can't find anywhere except on Packman (mad, xine, ffmpeg, ...). http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/factory/ http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/sle_11_sp1/ We would indeed be highly interested in also building for Tumbleweed, at the very least that "minimal" set of codec packages, and potentially more than that. I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees. On a side note, we use the openSUSE Build Service too, with our own instance, but it is linked with build.opensuse.org, which means that as soon as a dependency changes on build.o.o, a rebuild is triggered on our instance. This means that, exactly as with Factory, if Tumbleweed is built on build.o.o, rebuilds on Packman would be automatic. cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
On Tue, Nov 30, 2010 at 11:19:55PM +0100, Pascal Bleser wrote:
On 2010-11-30 22:31:15 (+0100), Guido Berhoerster <gber@opensuse.org> wrote:
* Greg KH <gregkh@suse.de> [2010-11-30 21:53]:
On Tue, Nov 30, 2010 at 10:37:01PM +0200, İsmail Dönmez wrote:
On Tue, Nov 30, 2010 at 10:26 PM, Greg KH <gregkh@suse.de> wrote: [skipping legal mambo jambo, possibly disagreed part]
(but on a side note, Greg, please stop assuming we package illegal stuff)
My apologies.
We would indeed be highly interested in also building for Tumbleweed, at the very least that "minimal" set of codec packages, and potentially more than that.
That's wonderful.
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees.
Understood.
On a side note, we use the openSUSE Build Service too, with our own instance, but it is linked with build.opensuse.org, which means that as soon as a dependency changes on build.o.o, a rebuild is triggered on our instance. This means that, exactly as with Factory, if Tumbleweed is built on build.o.o, rebuilds on Packman would be automatic.
Great, that's good to hear. thanks for clearing that up, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Moin, Am Tue, 30 Nov 2010 23:19:55 +0100 schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees.
because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...." But with an project like Tumbleweed wich has nearly the same goals as the PM-Repo, i would move my packages. ;) Detlef
On 2010-12-04 10:46:23 (+0100), Detlef Reichelt <detlef@die-mafia.de> wrote:
Am Tue, 30 Nov 2010 23:19:55 +0100 schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees.
because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...."
I agree, there are lots of packages that we have or used to have in Packman for historical reasons, in the sense that we were already packaging them there before the openSUSE Build Service even existed (or had those packages). Let's not forget that Packman was already around at S.u.S.E. Linux times :) The thing is though that there are at least as many people who complain that, with Packman, they do not only get the multimedia packages (codecs and many applications), but also updates for lots and lots of other stuff, and they don't want that. We can't please everyone I guess (although Tumbleweed might actually address part of that "problem"), and the concept we have been following for openSUSE is to split into repositories to enable people to pick what they want to update, at the expense of having to add multiple repositories. Yet the only repository that is not aligned with that concept is Packman. Another side effect of that, obviously, is duplicating work, a lot, and not getting the same package names or patches depending on whether you install from Packman or from, say, GNOME:Apps. And it's not like we have infinite resources (both human and build hardware wise) at Packman either :\
But with an project like Tumbleweed wich has nearly the same goals as the PM-Repo, i would move my packages. ;)
:) cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
On 2010-12-04 11:15:53 (+0100), Pascal Bleser <pascal.bleser@opensuse.org> wrote:
On 2010-12-04 10:46:23 (+0100), Detlef Reichelt <detlef@die-mafia.de> wrote:
Am Tue, 30 Nov 2010 23:19:55 +0100 schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees. because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...."
And, furthermore, to reduce duplication of work, we always have the option to move the packages over to build.o.o and _link them on Packman. That way, updates and patches are shared and only done once, but we can still provide the packages in the Packman repository ;) (but it still consumes build power on our infrastructure and doesn't alleviate the problem of people using Packman for multimedia also getting updates for those) cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
On Saturday December 4 2010 11:28:26 Pascal Bleser wrote:
On 2010-12-04 11:15:53 (+0100), Pascal Bleser <pascal.bleser@opensuse.org> wrote:
On 2010-12-04 10:46:23 (+0100), Detlef Reichelt <detlef@die-mafia.de> wrote:
Am Tue, 30 Nov 2010 23:19:55 +0100
schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees.
because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...."
And, furthermore, to reduce duplication of work, we always have the option to move the packages over to build.o.o and _link them on Packman. That way, updates and patches are shared and only done once, but we can still provide the packages in the Packman repository ;)
(but it still consumes build power on our infrastructure and doesn't alleviate the problem of people using Packman for multimedia also getting updates for those)
If that happens then people are "doing it wrong" cause the vendor stickiness prevents that. If they disable the vendor stickiness they have no reason to moan cause it is their own fault, not? regards, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2010-12-05 00:43:52 (+0100), Stephan Kleine <bitdealer@gmail.com> wrote:
On Saturday December 4 2010 11:28:26 Pascal Bleser wrote: [...]
(but it still consumes build power on our infrastructure and doesn't alleviate the problem of people using Packman for multimedia also getting updates for those)
If that happens then people are "doing it wrong" cause the vendor stickiness prevents that. If they disable the vendor stickiness they have no reason to moan cause it is their own fault, not?
Not sure I'd agree, because vendor stickiness still gets a lot of things wrong, especially in the sense that certain zypper actions don't behave as expected when vendor stickiness is enabled. Also, that vendor stickiness flag is global, not per-repository and, hence, while you might want to have everything updated from K:D:F, you might not want the claws-mail package from Packman. Priorities might solve that, but they're a bit awkward and, sadly, rather undocumented. cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
2010/12/5 Pascal Bleser <pascal.bleser@opensuse.org>:
On 2010-12-05 00:43:52 (+0100), Stephan Kleine <bitdealer@gmail.com> wrote:
On Saturday December 4 2010 11:28:26 Pascal Bleser wrote: [...]
(but it still consumes build power on our infrastructure and doesn't alleviate the problem of people using Packman for multimedia also getting updates for those)
If that happens then people are "doing it wrong" cause the vendor stickiness prevents that. If they disable the vendor stickiness they have no reason to moan cause it is their own fault, not?
Not sure I'd agree, because vendor stickiness still gets a lot of things wrong, especially in the sense that certain zypper actions don't behave as expected when vendor stickiness is enabled.
They behave as I expect.
Also, that vendor stickiness flag is global, not per-repository and, hence, while you might want to have everything updated from K:D:F, you might not want the claws-mail package from Packman.
Vendor stickness will disallow any of those if they aren't explicitly allowed. So do "zypper dup --from K:D:F" and manually select what you want to be updated from Packman (the explicit "allow")... and from now on "zypper up" will do its work.
Priorities might solve that, but they're a bit awkward and, sadly, rather undocumented.
Priorities are a *very* natural concept. "In any operation, if there is an option, packages from repos with a higher priority get preference" (and change vendor is not an option with anything but "zypper dup"). It's so simple, what's awkward with that? Only use Packman for multimedia is my user case, and I have no problems. Not for everybody, but with a ~30 lines lock file I can even use "zypper dup" to update my system, catching some problems in repos. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
* Pascal Bleser <pascal.bleser@opensuse.org> [Dec 05. 2010 01:10]:
Not sure I'd agree, because vendor stickiness still gets a lot of things wrong, especially in the sense that certain zypper actions don't behave as expected when vendor stickiness is enabled.
Also, that vendor stickiness flag is global, not per-repository and, hence, while you might want to have everything updated from K:D:F, you might not want the claws-mail package from Packman. Priorities might solve that, but they're a bit awkward and, sadly, rather undocumented.
This sounds like a couple of requests the folks at zypp-devel@opensuse.org would be happy to learn more about. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Pascal Bleser wrote:
On 2010-12-04 11:15:53 (+0100), Pascal Bleser <pascal.bleser@opensuse.org> wrote:
On 2010-12-04 10:46:23 (+0100), Detlef Reichelt <detlef@die-mafia.de> wrote:
Am Tue, 30 Nov 2010 23:19:55 +0100 schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees. because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...."
And, furthermore, to reduce duplication of work, we always have the option to move the packages over to build.o.o and _link them on Packman. That way, updates and patches are shared and only done once, but we can still provide the packages in the Packman repository ;)
Linking to Factory where possible would be nice. There are still packages that are packaged differently in Factory and Packman. It usually is no problem for either package maintainer to accept a merged package. The problem is just that someone needs to actually take the time and do the merge :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Saturday 04 December 2010 11:28:26 Pascal Bleser wrote:
On 2010-12-04 11:15:53 (+0100), Pascal Bleser <pascal.bleser@opensuse.org> wrote:
On 2010-12-04 10:46:23 (+0100), Detlef Reichelt <detlef@die-mafia.de> wrote:
Am Tue, 30 Nov 2010 23:19:55 +0100
schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees.
because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...."
And, furthermore, to reduce duplication of work, we always have the option to move the packages over to build.o.o and _link them on Packman. That way, updates and patches are shared and only done once, but we can still provide the packages in the Packman repository ;)
(but it still consumes build power on our infrastructure and doesn't alleviate the problem of people using Packman for multimedia also getting updates for those)
In case the openSUSE Foundation works out, we may should think about to move the openSUSE Build Service to an external place, controlled by the Foundation. if we succeed on this, we can merge current openSUSE OBS and packaman OBS into one instance. I think this would help a lot here, even when we might still want to keep some packages in seperate projects ... This is something what we should discuss, after there was a decision on the Foundation plans ... 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
* Pascal Bleser <pascal.bleser@opensuse.org> [2010-12-04 11:15]:
On 2010-12-04 10:46:23 (+0100), Detlef Reichelt <detlef@die-mafia.de> wrote:
Am Tue, 30 Nov 2010 23:19:55 +0100 schrieb Pascal Bleser <pascal.bleser@opensuse.org>:
I personally agree that packages that could also be on build.opensuse.org should go there instead of being in the Packman repository but, unfortunately, not everyone in the Packman team agrees.
because i don't want to split my packages in thousand repos on OBS. An example: I stopped building claws-mail on PackMan because it is in Gnome/Apps. After that i get many mails why i don't build it on PM anymore: "it was nice to have that in PM-Repo so it could be installed without add more repos...."
I agree, there are lots of packages that we have or used to have in Packman for historical reasons, in the sense that we were already packaging them there before the openSUSE Build Service even existed (or had those packages). Let's not forget that Packman was already around at S.u.S.E. Linux times :)
The thing is though that there are at least as many people who complain that, with Packman, they do not only get the multimedia packages (codecs and many applications), but also updates for lots and lots of other stuff, and they don't want that.
That could be solved technically by splitting Packman into two repositories, one with packages which cannot be included into openSUSE for legal reasons and one with everything else (and that sort of exists already for Factory). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Nov 30, 2010 at 21:26, Greg KH wrote:
Without Packman support for at least some of the key kmod's and codecs needed by tumbleweed, I seriously doubt it will get much end-user adoption.
I don't care about closed source kernel modules that violate my personal copyright, and neither should you.
There is a world of difference between a "working" install of openSUSE and an install that is considered useful by the Desktop user base. Thus the comment about key kmods and codecs is quite valid. Without that.... a tumbleweed distro (something I'm VERY interested in) drops to a passing curiosity. This is not to say that a tumbleweed can't have those extras, or must have them.. but they should be considered/be available in some form. C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Nov 30, 2010 at 10:00:04PM +0100, C wrote:
On Tue, Nov 30, 2010 at 21:26, Greg KH wrote:
Without Packman support for at least some of the key kmod's and codecs needed by tumbleweed, I seriously doubt it will get much end-user adoption.
I don't care about closed source kernel modules that violate my personal copyright, and neither should you.
There is a world of difference between a "working" install of openSUSE and an install that is considered useful by the Desktop user base. Thus the comment about key kmods and codecs is quite valid. Without that.... a tumbleweed distro (something I'm VERY interested in) drops to a passing curiosity.
This is not to say that a tumbleweed can't have those extras, or must have them.. but they should be considered/be available in some form.
Again, through the openSUSE infrastructure, we can not provide those extras, as everyone well knows. But, as always, it should be trivial to build them by third parties if they so desire. Tumbleweed would not take away that ability at all for anyone. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 30 November 2010 22:00:04 C wrote:
On Tue, Nov 30, 2010 at 21:26, Greg KH wrote:
Without Packman support for at least some of the key kmod's and codecs needed by tumbleweed, I seriously doubt it will get much end-user adoption.
I don't care about closed source kernel modules that violate my personal copyright, and neither should you.
There is a world of difference between a "working" install of openSUSE and an install that is considered useful by the Desktop user base. Thus the comment about key kmods and codecs is quite valid. Without that.... a tumbleweed distro (something I'm VERY interested in) drops to a passing curiosity.
If Tumbleweed turns out to be popular, I doubt the Packman team won't provide packages for it...
This is not to say that a tumbleweed can't have those extras, or must have them.. but they should be considered/be available in some form.
C.
On 2010-11-30 09:11:04 (-0800), Greg KH <gregkh@suse.de> wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences. So the time now is to stop talking about it, and actually trying to do it :) [...] So, any thoughts, ideas, objections?
Excellent idea! Just needs to be filled with manpower now ;) I think it's pretty clear how we could make rolling updates work, thanks to the awesomeness of the build service. But what should it include? The same as a shipped openSUSE release? More? Isn't it an "up-to-date and stable core system" + everything that's a stable release of anything on build.o.o ? Where do we draw the line ? Certainly something that needs some thought, opinions and discussion. cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
* Pascal Bleser <pascal.bleser@opensuse.org> [Nov 30. 2010 23:24]:
I think it's pretty clear how we could make rolling updates work, thanks to the awesomeness of the build service. But what should it include? The same as a shipped openSUSE release? More? Isn't it an "up-to-date and stable core system" + everything that's a stable release of anything on build.o.o ? Where do we draw the line ?
I would expect that 'subsystem maintainers' emerge, taking responsibility for specific parts of the whole distribution. This responsibility does not only include pushing 'stable' updates to the Tumbleweed release manager but also taking care about bug reports. And here is also the sweet spot for Tumbleweed. A bug would in most cases be fixed by pointing the user to the latest version. No more costly backporting of changes to previous versions. And the Tumbleweed release manager is acting as an integrator, accepting submit requests from the subsystem maintainers. Its up to those maintainers to draw the line, they're probably the only ones with sufficient knowledge about what might break with the update[1]. They will take the praise for up-to-date packages as well as the blame if their subsystem breaks. Having good feedback channels from users to maintainers is essential. I could imagine having this coupled with the 'app store' idea where packages/subsystems/maintainers get 'karma' based on user feedback. Klaus [1] Having an automated testsuite surely helps here. Hint, hint. --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2010-11-30 23:42:37 (+0100), Klaus Kaempf <kkaempf@suse.de> wrote:
* Pascal Bleser <pascal.bleser@opensuse.org> [Nov 30. 2010 23:24]:
I think it's pretty clear how we could make rolling updates work, thanks to the awesomeness of the build service. But what should it include? The same as a shipped openSUSE release? More? Isn't it an "up-to-date and stable core system" + everything that's a stable release of anything on build.o.o ? Where do we draw the line ?
I would expect that 'subsystem maintainers' emerge, taking responsibility for specific parts of the whole distribution.
This responsibility does not only include pushing 'stable' updates to the Tumbleweed release manager but also taking care about bug reports. [...] Its up to those maintainers to draw the line, they're probably the only ones with sufficient knowledge about what might break with the update[1]. They will take the praise for up-to-date packages as well as the blame if their subsystem breaks.
Yes, that's all fine, and what I was referring to with "it's pretty clear how we could make rolling updates work" :) But what about the amount of packages to include into Tumbleweed then? Same as openSUSE releases, or more? Because as we'll be able to have Tumbleweed as a build target (or "repository" in OBS-speak) in build.o.o, anything goes in the additional repositories as well. cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
On Tue, Nov 30, 2010 at 11:42:37PM +0100, Klaus Kaempf wrote:
* Pascal Bleser <pascal.bleser@opensuse.org> [Nov 30. 2010 23:24]:
I think it's pretty clear how we could make rolling updates work, thanks to the awesomeness of the build service. But what should it include? The same as a shipped openSUSE release?
Yes, it will start with that.
More?
What more is there that isn't already in the build system?
Isn't it an "up-to-date and stable core system" + everything that's a stable release of anything on build.o.o ? Where do we draw the line ?
Let's start with the 11.4 release and add-on as needed from there, ok?
I would expect that 'subsystem maintainers' emerge, taking responsibility for specific parts of the whole distribution.
This responsibility does not only include pushing 'stable' updates to the Tumbleweed release manager but also taking care about bug reports.
Yes, that is true.
And here is also the sweet spot for Tumbleweed. A bug would in most cases be fixed by pointing the user to the latest version. No more costly backporting of changes to previous versions.
Exactly, this should save time for the developers in charge of packages, ideally.
And the Tumbleweed release manager is acting as an integrator, accepting submit requests from the subsystem maintainers.
And poking the subsystem maintainers where needed :)
Its up to those maintainers to draw the line, they're probably the only ones with sufficient knowledge about what might break with the update[1]. They will take the praise for up-to-date packages as well as the blame if their subsystem breaks.
Having good feedback channels from users to maintainers is essential.
I could imagine having this coupled with the 'app store' idea where packages/subsystems/maintainers get 'karma' based on user feedback.
Hm, I don't want to get into that idea for now, let me just focus on this one thing. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mardi 30 novembre 2010, à 23:24 +0100, Pascal Bleser a écrit :
On 2010-11-30 09:11:04 (-0800), Greg KH <gregkh@suse.de> wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences. So the time now is to stop talking about it, and actually trying to do it :) [...] So, any thoughts, ideas, objections?
Excellent idea! Just needs to be filled with manpower now ;)
:-) 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. This of course means something from a manpower perspective, but there's a bigger risk in divergence: code/technical divergence, but also community divergence. On the other hand, I do understand that we probably want something with low overhead when it comes to submitting a change. So how should we do things? Can we require that all changes going in one will go to the other in some way too? Or do we need a model that is similar to Debian's one? To summarize, I don't want people to have to choose between our current way and the rolling release way -- if they do have to choose, they'll just go "oh well, I don't care about the other" and we'll be losing something. Cheers, 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
Hey, On 12/01/2010 09:18 AM, Vincent Untz wrote:
Le mardi 30 novembre 2010, à 23:24 +0100, Pascal Bleser a écrit :
On 2010-11-30 09:11:04 (-0800), Greg KH <gregkh@suse.de> wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences. So the time now is to stop talking about it, and actually trying to do it :) [...] So, any thoughts, ideas, objections?
Excellent idea! Just needs to be filled with manpower now ;)
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 it has to. We won't get instantly more package/project maintainers because of this. And all the existing package/project maintainers know whats "stable" right? So we only need a way to push what you deem "stable" also to this rolling update repo when you push it to factory. We used to do this in the dark ages (then it was called PLUS) as simple commandline switch to the submission command. Sounds like a simple osc plugin to me :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
* Vincent Untz <vuntz@opensuse.org> [2010-12-01 09:19]:
Le mardi 30 novembre 2010, à 23:24 +0100, Pascal Bleser a écrit :
On 2010-11-30 09:11:04 (-0800), Greg KH <gregkh@suse.de> wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences. So the time now is to stop talking about it, and actually trying to do it :) [...] So, any thoughts, ideas, objections?
Excellent idea! Just needs to be filled with manpower now ;)
:-)
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.
This of course means something from a manpower perspective, but there's a bigger risk in divergence: code/technical divergence, but also community divergence.
On the other hand, I do understand that we probably want something with low overhead when it comes to submitting a change.
So how should we do things? Can we require that all changes going in one will go to the other in some way too? Or do we need a model that is similar to Debian's one?
To summarize, I don't want people to have to choose between our current way and the rolling release way -- if they do have to choose, they'll just go "oh well, I don't care about the other" and we'll be losing something.
I share that concern, and in addition I also think that in some cases where package maintainers work on both the rolling release and Factory equally it will put additional load on them and thus divert resources which would otherwise be spent on the regular releases. This of course depends on the development project, some projects already maintain such continuously updated but relatively stable branches of their packages. But apart from the additional testing this also means dealing with additional bugreports. Not all bugs are simply solved by updating to newer versions, the combination of lower-level libraries and their higher-level consumers requires coordination efforts and testing to avoid occasional breakage as in Factory and on. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2010-12-01 12:24:07 (+0100), Guido Berhoerster <gber@opensuse.org> wrote:
* Vincent Untz <vuntz@opensuse.org> [2010-12-01 09:19]:
Le mardi 30 novembre 2010, à 23:24 +0100, Pascal Bleser a écrit :
On 2010-11-30 09:11:04 (-0800), Greg KH <gregkh@suse.de> wrote: [...] To summarize, I don't want people to have to choose between our current way and the rolling release way -- if they do have to choose, they'll just go "oh well, I don't care about the other" and we'll be losing something.
I share that concern, and in addition I also think that in some cases where package maintainers work on both the rolling release and Factory equally it will put additional load on them and thus divert resources which would otherwise be spent on the regular releases. This of course depends on the development project, some projects already maintain such continuously updated but relatively stable branches of their packages. But apart from the additional testing this also means dealing with additional bugreports. Not all bugs are simply solved by updating to newer versions, the combination of lower-level libraries and their higher-level consumers requires coordination efforts and testing to avoid occasional breakage as in Factory and on.
I don't see that happening, from the day to day workflow we have at maintaining packages in repositories (except openSUSE:Factory of course, that's a spechul one). As Henne said in another post on this thread, as package maintainers, we'd just do what we always did: upgrade packages when new upstream versions pop up. IMHO the differences/challenges are: * identifying and isolating certain "core" packages that are really critical regarding the stability of the system (kernel, init/systemd, hal, X.org, and a few others), and being a bit more conservative with those * finding a comfortable way to manage stable versions of all the other packages in Tumbleweed (e.g. linkpac against specific revisions ?) Sounds doable though. Sure, still needs more thought and discussing how we could try to make the system stabler than factory. But all the tools are in place ;) cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
On Thu, Dec 02, 2010 at 01:24:52AM +0100, Pascal Bleser wrote:
IMHO the differences/challenges are: * identifying and isolating certain "core" packages that are really critical regarding the stability of the system (kernel, init/systemd, hal, X.org, and a few others), and being a bit more conservative with those
Everything is critical if you rely on it and it breaks :)
* finding a comfortable way to manage stable versions of all the other packages in Tumbleweed (e.g. linkpac against specific revisions ?)
Those other packages will be able to be upgraded as well.
Sounds doable though. Sure, still needs more thought and discussing how we could try to make the system stabler than factory. But all the tools are in place ;)
Why not let us try it and we can see how well it all works out? That's better than thinking about it by far, especially as a lot of us have been thinking and talking about this for _years_ now. And some of us (myself included) have first-hand experience maintaining a distro that is "rolling", so it's not all that big of a deal. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mercredi 01 décembre 2010, à 20:07 -0800, Greg KH a écrit :
Why not let us try it and we can see how well it all works out? That's better than thinking about it by far, especially as a lot of us have been thinking and talking about this for _years_ now.
Sorry if my mail was perceived as stop energy. That was definitely not the intent, and I do agree we should just try to do it. I was just raising my concern as something to keep in mind when we do it :-) 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
On Wed, Dec 01, 2010 at 09:18:57AM +0100, Vincent Untz wrote:
Le mardi 30 novembre 2010, à 23:24 +0100, Pascal Bleser a écrit :
On 2010-11-30 09:11:04 (-0800), Greg KH <gregkh@suse.de> wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE on lots of different mailing lists and in person a different conferences. So the time now is to stop talking about it, and actually trying to do it :) [...] So, any thoughts, ideas, objections?
Excellent idea! Just needs to be filled with manpower now ;)
:-)
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 "contributors" having to do any different work here. They should be creating packages for Factory today, which is where the packages for Tumbleweed will come from, just after that same contributor deems them "stable" enough.
This of course means something from a manpower perspective, but there's a bigger risk in divergence: code/technical divergence, but also community divergence.
On the other hand, I do understand that we probably want something with low overhead when it comes to submitting a change.
So how should we do things? Can we require that all changes going in one will go to the other in some way too? Or do we need a model that is similar to Debian's one?
I totally do not understand your question here, care to rephrase it?
To summarize, I don't want people to have to choose between our current way and the rolling release way -- if they do have to choose, they'll just go "oh well, I don't care about the other" and we'll be losing something.
"people" can choose which repo to use, that's not going to hurt anyone here. "contributors" will still have the same workflow as before, just that they might get pinged every once in a while if their package should be sent to Tumbleweed or not. It's really not much of a difference at all for contributors, but the benifits for our users are quite high, if they want to use this type of rolling distro (as many have said they would like to do.) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mercredi 01 décembre 2010, à 14:05 -0800, Greg KH a écrit :
On Wed, Dec 01, 2010 at 09:18:57AM +0100, 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 "contributors" having to do any different work here. They should be creating packages for Factory today, which is where the packages for Tumbleweed will come from, just after that same contributor deems them "stable" enough.
That's the simple workflow. But let's take glib as an example (you can replace glib with any other package). Factory will have a development version of glib for a while, and my understanding is that it's not what we want in Tumbleweed. For Tumbleweed, we'll instead want to push updates from the stable glib branch. So the glib maintainers will have to "actively develop" two branches of the package. This is what is behind the concern I raised. I'm not too much worried about this for my packages since it turns out I'm part of a bigger team that works rather well. I'm more worried about packages that don't have a lot of people working on them but that are still important on your system. For those packages, it might be that people will choose to focus on the regular releases, or on Tumbleweed. But again, let's not block on this. It'll be easier to fix once we actually see how much of an issue it is. 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
On 2010-12-02 08:55:24 (+0100), Vincent Untz <vuntz@opensuse.org> wrote:
Le mercredi 01 décembre 2010, à 14:05 -0800, Greg KH a écrit :
On Wed, Dec 01, 2010 at 09:18:57AM +0100, 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 "contributors" having to do any different work here. They should be creating packages for Factory today, which is where the packages for Tumbleweed will come from, just after that same contributor deems them "stable" enough.
That's the simple workflow. But let's take glib as an example (you can replace glib with any other package). Factory will have a development version of glib for a while, and my understanding is that it's not what we want in Tumbleweed. For Tumbleweed, we'll instead want to push updates from the stable glib branch. So the glib maintainers will have to "actively develop" two branches of the package.
Ok, now I see your point. But it is quite specific to GNOME components (and certainly fits a few other projects), as with most upstream projects there is no specific split between "unstable" and "stable" branches. You often have beta versions and such, and those would _not_ be pushed to Tumbleweed (at least as far as my understanding goes :)), but when the next stable release is provided by upstream, we do push it to Tumbleweed. Of course, GNOME (and it also applies to KDE, if I'm not mistaken) is a pretty huge chunk of packages :) cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
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). openSUSE Updates do not have a strict version freeze. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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
Hey, On 11/30/2010 06:11 PM, Greg KH wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE
So the time now is to stop talking about it, and actually trying to do it :)
I like that attitude :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use. So, any thoughts, ideas, objections?
Yeah, you know me I always have an opinion. How about we use the repository that everybody already is using and that has the same purpose as you describe (Rolling and Feature updates), Packman, for this instead of creating yet another one. One of your goals is less repositories right? ;) All we would need for this is to make it possible to submit to packman from OBS. As the packman project also use the BS that shouldn't be too hard. Adrian? The packman team needs some more lovin' anyway as integral part of the openSUSE experience, so let's combine efforts! Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Dec 01, 2010 at 09:10:40AM +0100, Henne Vogelsang wrote:
Hey,
On 11/30/2010 06:11 PM, Greg KH wrote:
There's been many discussions over the past years about a "rolling update" version of openSUSE
So the time now is to stop talking about it, and actually trying to do it :)
I like that attitude :)
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use. So, any thoughts, ideas, objections?
Yeah, you know me I always have an opinion.
How about we use the repository that everybody already is using and that has the same purpose as you describe (Rolling and Feature updates), Packman, for this instead of creating yet another one. One of your goals is less repositories right? ;)
All we would need for this is to make it possible to submit to packman from OBS. As the packman project also use the BS that shouldn't be too hard. Adrian?
So you want to host this on Packman? Um, I think that would require a lot more resources on their side than on the openSUSE side at the moment, and not really for much benefit. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 2010-12-01 09:10:40 (+0100), Henne Vogelsang <hvogel@opensuse.org> wrote:
On 11/30/2010 06:11 PM, Greg KH wrote: [...]
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use. So, any thoughts, ideas, objections?
How about we use the repository that everybody already is using and that has the same purpose as you describe (Rolling and Feature updates), Packman, for this instead of creating yet another one. One of your goals is less repositories right? ;)
All we would need for this is to make it possible to submit to packman from OBS. As the packman project also use the BS that shouldn't be too hard. Adrian?
Ummm... I want the same thing! What did you just smoke? Our build power won't be able to cope with that, not even near. build.o.o is really the right place to maintain something like that, and have it as a target distro to build all other projects (in OBS-speak) against. Including Packman. And not the other way around :)
The packman team needs some more lovin' anyway as integral part of the openSUSE experience, so let's combine efforts!
That's true though ;) cheers -- -o) Pascal Bleser <pascal.bleser@opensuse.org> /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
On Thursday 02 December 2010 01:19:00 Pascal Bleser wrote:
On 2010-12-01 09:10:40 (+0100), Henne Vogelsang <hvogel@opensuse.org> wrote:
On 11/30/2010 06:11 PM, Greg KH wrote: [...]
So, I'd like to propose "openSUSE Tumbleweed" a repo that is a rolling updated version of openSUSE containing the latest "stable" versions of packages for people to use. So, any thoughts, ideas, objections?
How about we use the repository that everybody already is using and that has the same purpose as you describe (Rolling and Feature updates), Packman, for this instead of creating yet another one. One of your goals is less repositories right? ;)
All we would need for this is to make it possible to submit to packman from OBS. As the packman project also use the BS that shouldn't be too hard. Adrian?
it would be relative easy to support to create a submit request on packman OBS using openSUSE OBS as source (one day of work, including test cases). Submitting to an "unknown" OBS is more work, we have ideas, but it needs more conceptional and implementation work.
Ummm... I want the same thing! What did you just smoke?
Our build power won't be able to cope with that, not even near. build.o.o is really the right place to maintain something like that, and have it as a target distro to build all other projects (in OBS-speak) against. Including Packman. And not the other way around :)
IMHO, we should consider to unify the instances as mentioned before (but the Foundation is for sure a pre-requirement for this)...
The packman team needs some more lovin' anyway as integral part of the openSUSE experience, so let's combine efforts!
That's true though ;)
Any other suggestions where we can help to achieve this ? 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
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
On Monday 06 December 2010 11:55:17 Adrian Schröter wrote:
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).
In case we have an agreement that this is a good idea, I offer to write a concept proposal early next year for this. -- 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
On Mon, Dec 06, 2010 at 11:56:27AM +0100, Adrian Schröter wrote:
On Monday 06 December 2010 11:55:17 Adrian Schröter wrote:
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).
In case we have an agreement that this is a good idea, I offer to write a concept proposal early next year for this.
It's a nice idea, but voting can always be gamed, so I don't know how useful this really would be in the end. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 06 December 2010 10:41:08 Greg KH wrote:
On Mon, Dec 06, 2010 at 11:56:27AM +0100, Adrian Schröter wrote:
On Monday 06 December 2010 11:55:17 Adrian Schröter wrote:
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).
In case we have an agreement that this is a good idea, I offer to write a concept proposal early next year for this.
It's a nice idea, but voting can always be gamed, so I don't know how useful this really would be in the end.
well, I would more see it as reporting like "works for me", "did not solve the problem for me" or "update is harming my system". Only real user accounts would be able to say their opinion, so it can't be really gamed (at least as long we can avoid mass registrations). 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
On Monday 06 December 2010 20:08:34 Adrian Schröter wrote:
On Monday 06 December 2010 10:41:08 Greg KH wrote:
On Mon, Dec 06, 2010 at 11:56:27AM +0100, Adrian Schröter wrote:
On Monday 06 December 2010 11:55:17 Adrian Schröter wrote:
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).
In case we have an agreement that this is a good idea, I offer to write a concept proposal early next year for this.
It's a nice idea, but voting can always be gamed, so I don't know how useful this really would be in the end.
well, I would more see it as reporting like "works for me", "did not solve the problem for me" or "update is harming my system".
Only real user accounts would be able to say their opinion, so it can't be really gamed (at least as long we can avoid mass registrations).
And even then, why the heck would someone game that system? To break Tumbleweed? And wouldn't the maintainer probably notice it? There's still a human taking the final decision...
bye adrian
Adrian Schröter wrote:
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).
Great! We desperately need that feature for the updates we release already. This is how it looks for Fedora: https://admin.fedoraproject.org/updates/ cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (17)
-
Administrator -
Adrian Schröter -
C -
Cristian Morales Vega -
Detlef Reichelt -
Dirk Müller -
Greg Freemyer -
Greg KH -
Guido Berhoerster -
Henne Vogelsang -
İsmail Dönmez -
Jos Poortvliet -
Klaus Kaempf -
Ludwig Nussel -
Pascal Bleser -
Stephan Kleine -
Vincent Untz