Re: Revised wireless tree management practices

[Luciano Coelho <luciano.coelho@nokia.com>]

ext John W. Linville wrote:
> On Thu, Dec 10, 2009 at 08:14:34AM -0800, Luis R. Rodriguez wrote:
>> On Thu, Dec 10, 2009 at 7:03 AM, John W. Linville
>> <linville@tuxdriver.com> wrote:
> 
>>> Yes.  If you want me to do git pulls then you need to separate fixes
>>> into a tree based on wireless-2.6.  Also, you should be conscientious
>>> about adding "Cc: stable@kernel.org" to commit logs as appropriate.
>>> The whole point of the pulls is to keep me from having to touch
>>> the patches.
>> OK last question, is if we do take up the pull request method for
>> ath9k at Atheros we still have people sending patches from the
>> community so who would pick those up. Is it easier for you if we do so
>> and then get them to you through our pull request? How about the
>> stable fixes? Reason I ask if you pick some of these up it just means
>> we need to rebase and I do prefer to keep a clean tree myself as well,
>> although not required at all.
> 
> In the generic case, the driver/subsystem maintainer and I should
> negotiate that in advance -- either way might be acceptable and either
> way might call for special cases for individual patches.
> 
> So, feel free to propose how you would like to do it for ath9k in
> another thread or a private email.  But in general I would think that
> letting "outsider" (for lack of a better term) patches flow through
> a driver/subsystem maintainer tree would be acceptable.  After all,
> that implies a higher level of domain-specific review.

This is cool! I might consider sending pull-reqs for the wl1271 driver as well, 
so I don't send these patchbombs every now and then. ;) The advantage of this is 
that we can have a review round before the patches actually go in.  So we as the 
driver/subsystem maintainers can decide when the patches are ready to go to 
wireless-next-2.6.

Now it's my turn to ask a question... What happens in the case when there is an 
API change, say, in mac80211 that requires changes in a few different drivers? 
Those changes are usually done in a single patch that changes both the API and 
the affected drivers in one go.  In this case we will end up having to rebase 
our own trees.

How is this done in higher levels, for instance when something that changed in 
the net subsystem requires changes in the wireless "sub-subsystem"?


-- 
Cheers,
Luca.