Re: Revised wireless tree management practices

["John W. Linville" <linville@tuxdriver.com>]

On Mon, Dec 14, 2009 at 02:32:35PM +0200, Luciano Coelho wrote:
> 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"?

Well, git is really good at merges.  So in general things will "just
work".  In cases where you _need_ a patch that has been merged in my
tree you can just pull from me (possibly resolving merge conflicts)
and then continue from there.  But in many/most cases you can just not
worry about those things and I'll reserve conflicts in my tree instead.
Note that the above is true for driver-specific changes as well.
So for example if I were to merge a fix for iwlwifi, the iwlwifi tree
could either simply ignore the fix in their tree or pull from me to
get the fix before applying any following patches.

I would ask that before pulling from me you make sure that I have
pulled your latest round of preceding changes.  That way when you pull
from me it is a "fast forward" for your tree, and your pull requests
to me do not include many/any "pull from wireless-2.6" merge entries.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.