On Sun, Feb 20, 2011 at 11:12 PM, Greg KH
On Sun, Feb 20, 2011 at 10:55:23AM -0500, todd rme wrote:
On Sat, Feb 19, 2011 at 11:47 PM, Greg KH
wrote: On Sat, Feb 19, 2011 at 01:28:48PM -0500, todd rme wrote:
On Sat, Feb 19, 2011 at 1:11 PM, Hans Witvliet
wrote: On Sat, 2011-02-19 at 17:39 +0200, Angelos Tzotsos wrote:
On 02/19/2011 07:29 AM, Vahis wrote: > > > My server is 11.2 and I'll need to change soon. > I'm still dreaming of getting it somehow into a rolling mode :) > > Vahis
Same here. But I am also thinking that this will be my last upgrade to 11.3 (or 11.4) :)
-- While on the subject of Tumbleweed.... If you switch from a fixed version towards Tumbleweed, how about all the add-on repo's of the OBS?
afaics, they are still 11.2, 11.3, factory, SLE and some alien stuff.
hw
I would think they could add tumbleweed as a build target for these, just like the ones you listed are now.
No, and that is one of the main reasons why I don't want to have Tumbleweed be a stand-alone "product" or "release". To require this would add even more work to our packagers, and I do not want to do that at all.
How is is it more work? It takes all of about 10 seconds to add a new build target, and it is a one-time thing. That is the only way people will get stable, reliable packages from obs when using tumbleweed.
Packagers don't have to worry about Tumbleweed targets, I do.
Anyone setting up their own OBS repo WILL have to worry about tumbleweed targets.
On the contrary, I would say not having tumbleweed as a single build target will add much more work for anyone using obs.
See my other response where I detail the steps if you want your package in Tumbleweed, and how it is no extra work for you at all.
The problem isn't people who want their packages in tumbleweed, the problem is people who DON'T want their packages in tumbleweed (that is, pretty much the entire openSUSE build service).
Someone wanting to build their application against tumbleweed would need to need to set up repos for, 11.4, which is pretty easy (although it is slightly harder since the default naming won't work). However, then they have to manually modify the repo to include a second build target, which would not be anywhere near as easy. Further, they would have to modify this repo structure every time tumbleweed switches to a new version of openSUSE, compared to all the other repos which you can just make and then never touch again.
Again, if you are building for Factory, it should be fine for Tumbleweed. If not, I will resolve it.
What if factory has an unstable version and tumbleweed has an incompatible stable veron? That isn't just likely, it is absolutely certain to happen.
This also, as Cristian points out, makes things much harder for users. obs will be left without packages built against tumbleweed, which will likely lead to stability problems.
Users wouldn't be randomly picking packages from different repos, that's what Tumbleweed is supposed to solve here.
That would only work if the packages are in factory. There are a ton of packages in add-on repos that will never be in factory. There are also unstable versions of particular packages that users may want that, by definition, cannot be in tumbleweed, and often aren't even in factory.
This is ALL about making it easier for users first, and for packagers second.
Wait, what? When I brought up how having two repos makes it harder for users, you argued that you can't do it because it would make things more difficult for packagers. When I argued that it would ALSO make things more difficult for packagers, then you say that packagers don't matter and it should be made easier for users. I am getting confused about what exactly you are trying to accomplish here.
That would actually probably be a necessary first step, the semi-official (i.e. not home:) obs repos would need to set up tumbleweed as one of their build targets, get packages building successfully for tumbleweed, and only then think about submitting them for inclusion in tumbleweed.
Again, no, that's now how submitting stuff for tumbleweed works, sorry. It's as simple as doing your normal development and package submission you do today, yet when you feel something is "stable", either email me to let me know, or do a submitrequest for it. That's it.
Then what happens when it doesn't build? How do you expect them to test it? You have something stable, submit it to tumbleweed, then find out half the packages are broken. What do you do? Tumbleweed now has a half-working set of packages that wrecks peoples' systems when they do an update. Wouldn't it be better for them to find out about these problems before they submit?
That's what openSUSE:Tumbleweed:Testing is for, we've used it in the past, and will continue to use it. The yast2 problem was because I messed up the testing, not because the proceedure was wrong.
But what is the advantage of doing it this way? What is the problem with taking 10 seconds to add a new build target? I don't understand why this is such a bad thing. I add and remove build targets all the time in my own personal OBS repos, it isn't hard.
And further, what if the person has made ten changes to their repo since the last release, all that build off each other, and they find out that the first change was what broke things with tumbleweed. Now they have to go through and rework the remaining 9 changes to deal with the problem. On the other hand, if they had a build target up front they would have known about the problem at step 1 and could have fixed it then, saving them from re-doing everything. I think a couple instances like this and people would just stop using it.
A couple instances like that and I wouldn't take packages from that submitter anymore :)
But why not just avoid this problem entirely?
Adding a new repo in obs is, as I said, a 10-second affair if you are using a normal repo. Making it as easy as adding any other openSUSE release I think would encourage people to include it just like they do every other openSUSE release, which would mean they would find out about problems early and would mean that there is more software available for tumbleweed.
See the other reasons why a whole new repo is not a viable option, sorry.
I saw those reasons, and replied to them in some detail in a separate email. As I said there, I think they are either not really problems, or should be fixed in OBS rather than using sub-optimal workarounds in tumbleweed. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org