[opensuse-kernel] Increasing number of SUSE patches in kernel?
Hi all, I was under the (apparently wrong) impression, that one goal was, to get the openSUSE kernel closer to upstream. Now I see a constant stream of patches for e.g. Hyper-V going into Kernel:HEAD, tagged with fate numbers that cannot even be found on features.opensuse.org. That brought up the following questions: * is there really a valid usecase to putting lots of non-upstream(?) Hyper-V stuff into openSUSE kernels? Is there even a user who uses openSUSE on Hyper-V? * what about the former goal of bringing the openSUSE kernel closer to mainline, thus lowering the maintenance burden? Best regards, seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 02/22/2013 09:46 AM, Stefan Seyfried wrote:
Hi all,
I was under the (apparently wrong) impression, that one goal was, to get the openSUSE kernel closer to upstream.
That's my understanding as well.
Now I see a constant stream of patches for e.g. Hyper-V going into Kernel:HEAD, tagged with fate numbers that cannot even be found on features.opensuse.org.
That brought up the following questions: * is there really a valid usecase to putting lots of non-upstream(?) Hyper-V stuff into openSUSE kernels? Is there even a user who uses openSUSE on Hyper-V?
Just one comment regarding user: openSUSE is available in Azure which uses Hyper-V, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, Feb 22, Stefan Seyfried wrote:
That brought up the following questions: * is there really a valid usecase to putting lots of non-upstream(?) Hyper-V stuff into openSUSE kernels? Is there even a user who uses openSUSE on Hyper-V?
All the the changes go upstream, some may have to wait for the next merge window. My usecase, beside Azure, is that it can be tested almost right away by others and me without the need for a private tree.
* what about the former goal of bringing the openSUSE kernel closer to mainline, thus lowering the maintenance burden?
Where should the line be drawn? Sticking with kernel-vanilla for Factory? Olaf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/22/13 4:22 AM, Olaf Hering wrote:
On Fri, Feb 22, Stefan Seyfried wrote:
That brought up the following questions: * is there really a valid usecase to putting lots of non-upstream(?) Hyper-V stuff into openSUSE kernels? Is there even a user who uses openSUSE on Hyper-V?
All the the changes go upstream, some may have to wait for the next merge window. My usecase, beside Azure, is that it can be tested almost right away by others and me without the need for a private tree.
* what about the former goal of bringing the openSUSE kernel closer to mainline, thus lowering the maintenance burden?
Where should the line be drawn? Sticking with kernel-vanilla for Factory?
Unless there's a compelling reason, yes. Ease of testing may not be one, but Azure enablement is. There is another argument associated with this as well and I would like to see this one resolved. I have no problem with backports coming into the kernel if there's a compelling reason to include them (see above). What I do object to is the Factory kernel being used to hold experimental features. Most of your -hv- patches are tagged with some variant of Patch-mainline: Submitted. That's not the same as a backport. Until it lands in a maintainer tree, it's not a backport and shouldn't be added to the Factory kernel without some discussion. If they've actually been accepted into a maintainer branch, the tags should be updated appropriately. We'll never actually reach kernel-vanilla for Factory. There are groups of patches that implement features that we've deemed important enough to override that rule to enable: Xen, overlayfs, dm-raid45, richacls, and things to make it easier to have multiple kernel packages installed simultaneously lead the list. Stefan's complaint about there not being an openSUSE FATE request for it is valid though. Those should really be cloned over if we're pulling code in. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJRJ4wcAAoJEB57S2MheeWyh5kP/00z2cXp+9aj1fSBQzxSXwke BKfX/vB8POCS4nijewBUA1QIAZeT/6I1r+6AJz57h0xVAfhJeWbELnzHs30HSRip I4MSioggPThpjmosGdT/JUQq4nIIpkbp2GAIdagf9mIwZd9r3HLIgkmp2VHIWBEC XYOI50Rj9baGMCeGGVhGEhXARqu6cAX1uPf2vDP1NiKLbCWgSdVWvxf4rdAKZvBb u0hJ6kc50N8q+j2mLVRcUCDm2Hy6LZcGNqT9GyUvne5jz3/gtwtr4386as0kVtQc d9ylOkb90XnANYXSm+j5zR6iqtV+mI3MbhOd9OGYBmBa3NbIslymB1Ju/q8TzgBK AcL4ILWJXy2yO74++gzZA/T0RgqAaEiEHw440plDWa4mkaAkioujHxcXvi54qqAH Nj/3ZWaPzB4NZN+fNJY6yeX3AXqempFb8fXTPSf7E7WpwTw5E+wKniJHMauhKtoQ AbqUGwafZp9qsHGRUHv03hSWOdg8pV8/ii2WPnt+gByF+/WLlSw2UZCjzQ5JWdab zSS03an6VlszWzWkml+VLInKWOjmhZTIYUCNUwJkeYbkErqVd9y/qrbnfMxnKxp+ ZaOKaE1CQhbjHxfHOjoRel/52jddNZ39LCnuy1ueciWu+gE2RM70nTxr1Et1/q+R MTDYBgntCF4PcJ+ACTb1 =3eoj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (4)
-
Andreas Jaeger -
Jeff Mahoney -
Olaf Hering -
Stefan Seyfried