[opensuse-kernel] Kernel projects
[Sorry for the resend, Coolo - accidentally sent it from my personal address] Hi Coolo - Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve. Here's my concern. Kernel:HEAD serves two purposes which are going to conflict in the next week or so. The first is that it contains a reasonably up-to-date snapshot of the master kernel git repo. The second is that it serves as a devel project for openSUSE:Factory. In the next week, 2.6.32-rc2 will be released and that is usually when I start revving the master kernel to sync up with the latest upstream snapshot. With the current setup, that will end up putting untested and potentially unstable code in the devel project, which appears to be synced fairly frequently into openSUSE:Factory. That's not what we want, obviously. OTOH, the KOTD HEAD/master kernel has always been the bleeding edge and I don't want to change that either. We can sync the 11.2 tree to Kernel:HEAD after the split, but then we lose the testing we regularly get from having that repo. OTOH, if we add another kernel package, and use that as the devel project, then we can keep Kernel:HEAD the way it is and preserve openSUSE:Factory as well. Do you have an opinion here? Thanks. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
At Thu, 01 Oct 2009 16:24:43 -0400, Jeff Mahoney wrote:
[Sorry for the resend, Coolo - accidentally sent it from my personal address]
Hi Coolo -
Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve.
Here's my concern. Kernel:HEAD serves two purposes which are going to conflict in the next week or so. The first is that it contains a reasonably up-to-date snapshot of the master kernel git repo. The second is that it serves as a devel project for openSUSE:Factory.
In the next week, 2.6.32-rc2 will be released and that is usually when I start revving the master kernel to sync up with the latest upstream snapshot.
With the current setup, that will end up putting untested and potentially unstable code in the devel project, which appears to be synced fairly frequently into openSUSE:Factory. That's not what we want, obviously. OTOH, the KOTD HEAD/master kernel has always been the bleeding edge and I don't want to change that either.
We can sync the 11.2 tree to Kernel:HEAD after the split, but then we lose the testing we regularly get from having that repo. OTOH, if we add another kernel package, and use that as the devel project, then we can keep Kernel:HEAD the way it is and preserve openSUSE:Factory as well.
I think this is a general problem found in other devel projects, too. As we are in the version freeze for 11.2, no development is allowed in devel project :) It'd be nice if we have a generic rule about this. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Am Freitag 02 Oktober 2009 schrieb Takashi Iwai:
At Thu, 01 Oct 2009 16:24:43 -0400,
Hi,
Jeff Mahoney wrote:
[Sorry for the resend, Coolo - accidentally sent it from my personal address]
Hi Coolo -
Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve.
GNOME and KDE maintain their factory packages in :Factory and use it also for people who want the lasted GNOME/KDE on older distributions. So it's bleeding edge as far as openSUSE is concerned. KDE has also :UNSTABLE, which contains random svn snapshots that have no relation to factory packages. I don't think there is something similiar for GNOME.
Here's my concern. Kernel:HEAD serves two purposes which are going to conflict in the next week or so. The first is that it contains a reasonably up-to-date snapshot of the master kernel git repo. The second is that it serves as a devel project for openSUSE:Factory.
In the next week, 2.6.32-rc2 will be released and that is usually when I start revving the master kernel to sync up with the latest upstream snapshot.
Why would you do that? Why would you want to split between master and 11.2 branch that early?
With the current setup, that will end up putting untested and potentially unstable code in the devel project, which appears to be synced fairly frequently into openSUSE:Factory. That's not what we want,
No, I synced it 2 times because of important bug reports. We can push to O:F from any other project like Kernel:112_BRANCH, there is no problem with that. There is no automatism that pushes :Head - it's just me :)
obviously. OTOH, the KOTD HEAD/master kernel has always been the bleeding edge and I don't want to change that either.
We can sync the 11.2 tree to Kernel:HEAD after the split, but then we lose the testing we regularly get from having that repo. OTOH, if we add another kernel package, and use that as the devel project, then we can keep Kernel:HEAD the way it is and preserve openSUSE:Factory as well. Actually I don't see the value of having 2.6.32-rc2 in master branch. And if there is, then you need to create a 112_BRANCH project _now_ and you can use it to push updates to O:F bypassing the devel project.
This is similiar to devel:languages:perl, where there is already a newer perl than what we'll have in 11.2. Perl updates are pushed now from direct factory copies.
I think this is a general problem found in other devel projects, too. As we are in the version freeze for 11.2, no development is allowed in devel project :) It'd be nice if we have a generic rule about this.
There is a reason we put 11.2 in version freeze: a) so people test a pretty fixed set of packages for a longer time b) so developers fix bugs instead of updating to unrelated versions Don't get me wrong, but I see 75 bugs reported against "Kernel", so if someone tests 2.6.32-rc2 is the least of my worries. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
At Fri, 2 Oct 2009 10:14:19 +0200, Stephan Kulow wrote:
Am Freitag 02 Oktober 2009 schrieb Takashi Iwai:
At Thu, 01 Oct 2009 16:24:43 -0400,
Hi,
Jeff Mahoney wrote:
[Sorry for the resend, Coolo - accidentally sent it from my personal address]
Hi Coolo -
Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve.
GNOME and KDE maintain their factory packages in :Factory and use it also for people who want the lasted GNOME/KDE on older distributions. So it's bleeding edge as far as openSUSE is concerned. KDE has also :UNSTABLE, which contains random svn snapshots that have no relation to factory packages. I don't think there is something similiar for GNOME.
So, :UNSTABLE would correspond to 2.6.32 :)
Here's my concern. Kernel:HEAD serves two purposes which are going to conflict in the next week or so. The first is that it contains a reasonably up-to-date snapshot of the master kernel git repo. The second is that it serves as a devel project for openSUSE:Factory.
In the next week, 2.6.32-rc2 will be released and that is usually when I start revving the master kernel to sync up with the latest upstream snapshot. Why would you do that? Why would you want to split between master and 11.2 branch that early?
Partly because this would help debugging. It can be indeed a help for both FACTORY and upstream. Assume you get a bug on 11.2 kernel. Developers usually would like to know first whether it's already fixed on the latest kernel. Providing a test kernel package is a great help for users so that they can test without compiling by themselves. Of course, this is good for the upstream development, too, which will get back to us later in turn. (snip)
I think this is a general problem found in other devel projects, too. As we are in the version freeze for 11.2, no development is allowed in devel project :) It'd be nice if we have a generic rule about this.
There is a reason we put 11.2 in version freeze: a) so people test a pretty fixed set of packages for a longer time b) so developers fix bugs instead of updating to unrelated versions
I'm not against the version freeze of FACTORY. I'm actually for it. Anyway, my concern is that there are many doubled meanings in devel-projects -- the development repo for FACTORY, and the development repo for the projects (and sometimes the projects hosting backports for old distros). As now, most projects have been moved to devel projects served as the first purpose. Then, suddenly people noticed that they can't update to the newer version now, and no idea where to move. Many people provide the update version in home:* project instead, which is hard to find for users. So, what I'm saying is that we need a common naming rule of the projects for the latest upstream / test packages, like :UNSTABLE. Kernel could be a bit different, BTW. I think Kernel: can contain 2.6.* projects containing the last SUSE kernel packages of the corresponding kernel versions. (Look at home:tiwai:kernel:2.6.* projects.)
Don't get me wrong, but I see 75 bugs reported against "Kernel", so if someone tests 2.6.32-rc2 is the least of my worries.
All 2.6.32-rc2 bugs can be simply passed to bugzilla.kernel.org, and bnc can be closed as RESOLVED:UPSTREAM. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 10/02/2009 04:14 AM, Stephan Kulow wrote:
Am Freitag 02 Oktober 2009 schrieb Takashi Iwai:
At Thu, 01 Oct 2009 16:24:43 -0400, Jeff Mahoney wrote:
Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve.
GNOME and KDE maintain their factory packages in :Factory and use it also for people who want the lasted GNOME/KDE on older distributions. So it's bleeding edge as far as openSUSE is concerned. KDE has also :UNSTABLE, which contains random svn snapshots that have no relation to factory packages. I don't think there is something similiar for GNOME.
Ok, so my understanding there was wrong then. This is a pretty common complaint about the build service from community members. There are so many projects and no clear definition as to which is which without having access to the build service to read the project description. I think having all these different projects is great and necessary for a true community driven openSUSE, but it can get confusing pretty quickly. If there is no standard convention, perhaps we'll just keep Kernel:HEAD as our "UNSTABLE" and create a new release development branch when we branch HEAD from the current factory.
With the current setup, that will end up putting untested and potentially unstable code in the devel project, which appears to be synced fairly frequently into openSUSE:Factory. That's not what we want, No, I synced it 2 times because of important bug reports. We can push to O:F from any other project like Kernel:112_BRANCH, there is no problem with that. There is no automatism that pushes :Head - it's just me :)
obviously. OTOH, the KOTD HEAD/master kernel has always been the bleeding edge and I don't want to change that either.
We can sync the 11.2 tree to Kernel:HEAD after the split, but then we lose the testing we regularly get from having that repo. OTOH, if we add another kernel package, and use that as the devel project, then we can keep Kernel:HEAD the way it is and preserve openSUSE:Factory as well. Actually I don't see the value of having 2.6.32-rc2 in master branch. And if there is, then you need to create a 112_BRANCH project _now_ and you can use it to push updates to O:F bypassing the devel project.
This is similiar to devel:languages:perl, where there is already a newer perl than what we'll have in 11.2. Perl updates are pushed now from direct factory copies.
I think this is a general problem found in other devel projects, too. As we are in the version freeze for 11.2, no development is allowed in devel project :) It'd be nice if we have a generic rule about this.
There is a reason we put 11.2 in version freeze: a) so people test a pretty fixed set of packages for a longer time b) so developers fix bugs instead of updating to unrelated versions
Don't get me wrong, but I see 75 bugs reported against "Kernel", so if someone tests 2.6.32-rc2 is the least of my worries.
With a giant upstream community producing a moving target, motivated testers are often willing to test the next prerelease to see if their problem is already fixed. Then it's *much* easier to fix the openSUSE release since the work is reduced from duplicating effort to develop a patch to just isolating the patch that fixed the problem. This is something we've historically done anyway. The only question I had was in relation to the build service. We don't expect many users to update to an early rc unless they are asked or have a reason for it. In some cases, our users want to assist in upstream development by running the vanilla kernel, so providing those packages helps us all out as Takashi's already noted. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney napsal(a):
Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve.
To branch or not to branch discussion aside, technically we just temporarily switch the devel project to Kernel:os-11.2 and once Factory is open again, we switch it back. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 10/02/2009 05:02 AM, Michal Marek wrote:
Jeff Mahoney napsal(a):
Quick question for you on how the kernel projects on the build service should be structured. I've noticed GNOME and KDE have :Factory projects, but I'm unclear on their uses. Are the GNOME and KDE projects the devel projects and the GNOME:Factory and KDE:Factory projects the bleeding edge? Is there a cascade effect where changes start in :Factory, then flow into the regular repo, and then into the openSUSE:Factory project? If that's the case, then my problem is easy enough to solve.
To branch or not to branch discussion aside, technically we just temporarily switch the devel project to Kernel:os-11.2 and once Factory is open again, we switch it back.
Perhaps we should change the tool so that we can automatically sync all the branches to their corresponding devel projects based on a map. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (4)
-
Jeff Mahoney -
Michal Marek -
Stephan Kulow -
Takashi Iwai