Search Linux Wireless

Re: Revised wireless tree management practices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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@xxxxxxxxxx" 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux