![](https://seccdn.libravatar.org/avatar/bcd65ca98f9d97839f15c54575c7edec.jpg?s=120&d=mm&r=g)
On 1/15/14, 5:12 AM, Stephan Kulow wrote:
On 15.01.2014 11:04, Takashi Iwai wrote:
At Wed, 15 Jan 2014 10:27:12 +0100, Jiri Slaby wrote:
On 01/14/2014 03:40 PM, Takashi Iwai wrote:
At Mon, 13 Jan 2014 21:30:30 +0100, Jiri Slaby wrote:
On 01/13/2014 11:38 AM, Takashi Iwai wrote:
>> Or what about just taking stable branch? It can be either temporarily >> taken until the new kernel is released, or we can use always stable >> branch for FACTORY. >> > I would be fine with always taking stable branch. As factory is supposed > to be stable itself, that sounds like a good idea in general :)
Jiri, what do you think?
I don't mind; stable is there for you to take it, if you want :).
BUT: where is the "next" kernel going to be tested then?
Do you mean linux-next, or the current rc kernels?
Oh, I meant rc kernels.
That is, should we let stable for Tumbleweed, and rather FACTORY testing rc kernels?
I thought that using stable kernel for FACTORY would align to the policy we're trying to achieve recently -- make FACTORY stable / usable. But, of course, this cuts off the side as a tester.
This was exactly my point. But I'm not biased to any of the sides. For me, both have equal pros&cons.
I guess it's a call for Jeff and Coolo, then :)
I have no problem with having RC kernels in factory - if they work, including xen support. I'm fine with changing the devel project of the kernel, but the stable kernel needs to be submitted to factory then. Right now Michal creates a submit request to factory whenever his script changes Kernel:HEAD. If that could be changed to only do so if it's the devel project and we have something similiar for Kernel:Stable, I could play the director.
I don't have a strong opinion on what kernel ends up in Factory, so long as Kernel:HEAD still tracks -rc releases the way it has been. Michal could probably automate the submissions to pick from Kernel:Stable vs Kernel:HEAD based on the contents of HEAD (rc? Xen present? really we could use any heuristic here). The only hiccup would be automating the swapping of the devel project.
The real problem I'm having with this: it reduces the pressure to fix xen patches support for RCs even more.
I don't think pressure from Factory has anything to do with the patches getting updated on RCs. The developers responsible for those have very full plates and the patches get updated when there's time. This cycle took a bit longer than is typical, but it also crossed the holidays when most of us where on vacation anyway. -Jeff -- Jeff Mahoney SUSE Labs