-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2009 01:09 PM, Larry Finger wrote:
On 12/15/2009 11:44 AM, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/15/2009 12:20 PM, Larry Finger wrote:
On 12/14/2009 07:09 PM, Jeff Mahoney wrote:
I think this is a good idea. The current policy heavily penalizes the user whose hardware was supported by the kernel that was released just after the distro was frozen. Most of my activity is with wireless drivers, which have many changes with each kernel release, as well as manufacturers releasing new hardware on a regular basis.
For me, kernel 2.6.32 is much more usable than 2.6.31 because one of my devices is a Broadcom BCM4312. It must be said, however, that the changes needed to support that chip are likely to be too invasive to fit under your guidelines. That will be the hardest part of implementing the proposed changes - how invasive can the changes be?
Does your proposed new policy automatically exclude those drivers in staging?
I'm not sure what you mean here. Do you mean updating staging/ drivers or adding new ones? I have no problem adding new staging/ drivers. They definitely fit the "standalone" requirement.
The question really was whether your phrase "mainline drivers" included those in "staging". From what you say below, it obviously does.
I don't have any objections to revving staging/ drivers in general. Most changes will only improve their quality. I don't really want to say that it will happen automatically, though. That ends up being quite a lot of work for kernel teams that are already heavily overloaded.
OTOH, now that we have a public git repo, I wouldn't be opposed accepting pull requests that rev staging drivers. There are a lot of things we could end up doing that we haven't in the past if we have more community involvement.
With git, the pull from staging shouldn't cause the kernel teams too much effort to get them to build. The fact that driver is in staging removes a lot of guarantees. In addition, those drivers are generally in better shape than the initial version of the vendor's driver, which is likely the user's only other option. At least this is true for Realtek's rtl8187se driver.
Well, "too much effort" is relative. Our kernel teams are currently doing maintenance for multiple code streams as well as developing SLE11 SP1 and openSUSE 11.3. I'm sure you can imagine where backporting the staging drivers falls on the list of priorities. Pulling direct from mainline doesn't work since our git repo isn't an expanded tree. It's a repository of patches that get applied in sequence. Backporting the drivers means manually cherry picking out the changes and rolling them into patches that apply to our tree. This makes it painful for things like this, but has _huge_ advantages in other areas. What I meant by accepting pull requests is that if someone finds a driver that has changes that fixes an issue they're observing on their own hardware and wants to put the effort into backporting the patch into their own copy of our git repo, I wouldn't be opposed to accepting it into our repo. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksn1zUACgkQLPWxlyuTD7JSZwCfUVG0Ku0oBCqTP53Lmi+hIAY3 BAAAoIDnGA8BPHb7VvDRDlt8DAKVGCV9 =4VdZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org