On Tue, 2007-07-10 at 13:12 -0400, John W. Linville wrote: > > > which is not upstream. Merging it upstream would mean taking the patch from > > > wireless-dev git and manually modifying it to fit a new structure. And we > > > have a bunch of such patches which should go to 2.6.24 (yes, I really > > > mean .24). Perhaps I'm lazy, but I'd like to avoid that. It's going to be a > > > lot of unpleasant work even without this... > Hmmmm...maybe. But, what would have been the perfect trigger to > merge it? At least now we have less bits out-of-stream and have to > do less API-chasing with every new kernel. Dunno. I guess I didn't expect Jiri to block any patches based on the fact that we have two trees now. I don't really see the big problem anyhow. As long as we don't want any patches in upstream that depend on the refactoring we can delay pushing the refactoring upstream. Once we do get patches we can decide to either make two versions of them or at some point push the refactoring upstream as well; problems will only arise if we delay too much pushing patches upstream that are before the refactoring, those would need to be rediffed. Oh well. Do what you feel is easiest. This is the second or third time I've been burnt with significant mac80211 cleanups so I guess I'll just learn my lesson here. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
