On 1/25/12 5:30 AM, Dave Taht wrote: > "A second, large problem (in my mind), is that I would like to find a > process for getting stuff upstream into the mainline kernel." > > Returning to handling the patch backlog: > > One way to perhaps help this is for the overall schedule to be more > widely publicised and to work on more of a time based manner. > In my case I've been trying to adhere to the kernel release schedule > + .1 + X, where .1 is the first followup to the 'stable' kernel release, > where X is the delta that it seems to take between a release and > patches appearing.
My problem is the opposite. I use x86 hardware because it's what I have, and ath5k hardware for the same reason. I'm told that my patches languish because they are for 2.6.39.4 (or whatever) and I'm encouraged to go to a newer kernel... but I can't because all of the churn with the ath9k goes untested and tends to be extremely destabilizing to the ath5k drivers. Hence I'm *forced* to use the 2.6.39.x if I want a machine that even boots. Ironically, my patches are being held back because they're not sufficiently 'vetted', but the reason they aren't vetted is because I can't even get a box to boot with other people's insufficiently vetted ath-common changes! So my lack of vetting is the symptom, but not the cause. I'll be happy to boot 3.2 if and when I can, which is to say when the atheros patches are adequately tested for ath5k. Or we can simply state that the ath5k isn't supported hardware in OpenWRT, and I'll throw them in the trash can and move on and order an Ath9k card from Amazon. Which is it to be? -Philip _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
