On Sun, Dec 12, 2010 at 12:35:18PM -0500, Greg Freemyer wrote:
On Sun, Dec 12, 2010 at 12:12 PM, Philipp Thomas <Philipp.Thomas2@gmx.net> wrote:
On Sun, 12 Dec 2010 13:18:20 +0100, Stefan Dirsch <sndirsch@suse.de> wrote:
And breaking other's repos is any better?
Where did I say that? I still think that given the BS turnaround times it would be better to have a testbed repo where things can be dropped in to be tested.
I fully agree with you that such changes should be well tested before being allowed into an official repo.
I haven't followed the full issue here, but I hope / assume that there will be a Tumbleweed testing repo before this is process is fully baked.
No, no, no. Please keep this process simple. All of us are willing to drive Tumbleweed _while_ we need to kept focused. At the time we created network:samba:STABLE and TESTING we had a long discussion regarding if we need network:samba:3_2, n:s:3_3, n:s:3_4 and so on. And I always argued: keep it simple. Less repositories are better and focus the testing. Using an additional repositories from the openSUSE Build Service (OBS) is already hard enough for the majority of our users. Short messager: less repositories are better. All the extra or additional repositories we're able to offer with the OBS are causing to much headache to the majority of the users. Why else do we need a document about how to use the Samba repositories at http://en.openSUSE.org/Samba ? You might argue that the way how we've organized it for Samba is very specific. To me it's the result of many years we're offering Samba binaries to our users. We already had TESTING and STABLE playgrounds for Samba at the time while we had been limited to ftp.suse.com/pub/projects/samba , download.samba.org/samba/ftp/Binary_Packages/SuSE/ and the mirrors.
Packages get submitted there first. If they work well for a week or two, then they go to the real tumbleweed repo.
The team maintaining a project at the OBS has to care about this. Every project member has to be aware of the potential risk. Why not using Factory to address your concerns?
Conceivably Factory could serve that purpose, but often factory has already progressed past what is being considered for tumbleweed. (ie. The tumbleweed kernel is currently 2.6.36, but factory is 2.6.37-rc, so in the long run, 2.6.36 should be tested in tumbleweed-testing for a while before being pushed to tumbleweed.
But Factory needs to be feeded from somewhere. I believe at this places/ locations we are already able to address your concerns.
I assume the same will true for X, KDE, Gnome, etc. They will need a way to do integration testing with tumbleweed before tumbleweed gets upgraded.
fyi: If all this works out, it seems tumbleweed would be source of 1full distro releases (starting with 11.5) and thus release freezes, etc. could happen there. Then factory could have a lot of the freezes, etc. removed. I think that too would make a lot of developers happy.
Yes. That's how it might work out at the end. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany