[ANN] new wireless stack trees

[ANN] new wireless stack trees

[Johannes Berg]

Hi,

Given the amount of work going on in the various wireless stack
components, I've decided that I'll reflect my maintainer role also in
git trees. I've created new trees and will pick patches for
 * mac80211
 * cfg80211
 * rfkill (if needed)

into the new trees
 * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211.git;a=summary
 * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=summary

Yes, I've called them "mac80211", but I will also pick up the other
components into them. Calling them "wireless" would have been too
confusing.

These trees feed John's wireless and wireless-next trees respectively.

I won't maintain an integration tree like John's wireless-testing,
please continue to use his. If merge conflicts make it necessary, I'll
resolve them in separate branches etc. and work it out with John.

I will probably ask for these trees to be included in linux-next, but I
need a bit of ramp-up time before that I think :-)


As a result, I ask you to not submit patch series that touch both your
driver and the stack, please submit them independently. John will have
to wait applying the patches to the driver until has has pulled in any
dependencies via my trees.

If you maintain your own driver trees you're free to merge these trees
if you need their contents, but please don't send my contents to John
yourself, wait with your merge requests and nag me if you need me to
push to John :-)

A word of caution though: I've not done this before, so while I think I
know what I'm signing up for I'm sure I'll make mistakes. If you pull my
tree in and I have to rebase due to those mistakes then would have to
rebase as well, so maybe don't pull it tomorrow but give me some time to
adjust to the workflow.


Of course I'll continue to post my own patches to the mailing list well
before I applying them.

johannes

Re: [ANN] new wireless stack trees

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> Given the amount of work going on in the various wireless stack
> components, I've decided that I'll reflect my maintainer role also in
> git trees. I've created new trees and will pick patches for
>  * mac80211
>  * cfg80211
>  * rfkill (if needed)
>
> into the new trees
>  * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211.git;a=summary
>  * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=summary

Great!

> I won't maintain an integration tree like John's wireless-testing,
> please continue to use his. If merge conflicts make it necessary, I'll
> resolve them in separate branches etc. and work it out with John.

So when working on mac80211 or cfg80211 changes you still recommend the
developer to use wireless-testing, did I understand this correctly?

-- 
Kalle Valo

Re: [ANN] new wireless stack trees

[Johannes Berg]

On Wed, 2012-06-06 at 10:00 +0300, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > Given the amount of work going on in the various wireless stack
> > components, I've decided that I'll reflect my maintainer role also in
> > git trees. I've created new trees and will pick patches for
> >  * mac80211
> >  * cfg80211
> >  * rfkill (if needed)
> >
> > into the new trees
> >  * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211.git;a=summary
> >  * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=summary
> 
> Great!
> 
> > I won't maintain an integration tree like John's wireless-testing,
> > please continue to use his. If merge conflicts make it necessary, I'll
> > resolve them in separate branches etc. and work it out with John.
> 
> So when working on mac80211 or cfg80211 changes you still recommend the
> developer to use wireless-testing, did I understand this correctly?

Most of the time, I probably won't care. You might want to give me hints
as to which tree I should apply the patch to but I'm pretty confident I
can also make that call most of the time :-)

johannes

Re: [ANN] new wireless stack trees

[Arend van Spriel]

On 06/05/2012 02:11 PM, Johannes Berg wrote:
> Hi,
> 
> Given the amount of work going on in the various wireless stack
> components, I've decided that I'll reflect my maintainer role also in
> git trees. I've created new trees and will pick patches for
>  * mac80211
>  * cfg80211
>  * rfkill (if needed)
> 
> into the new trees
>  * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211.git;a=summary
>  * http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=summary
> 
> Yes, I've called them "mac80211", but I will also pick up the other
> components into them. Calling them "wireless" would have been too
> confusing.
> 
> These trees feed John's wireless and wireless-next trees respectively.

Hi Johannes,

Although I can see the reason for maintaining the wireless stack
separately from the wireless drivers, I would like to give my concerns
about this idea.

While separating maintenance makes sense, moving to a separate
repository impairs development in the wireless arena given the close
relation between mac80211 stack and drivers and it will surely add
latency. Integration between mac80211 and drivers will occur somewhat
later and when issues are found in that area the fixes (at least
mac80211 fixes) will add additional delay.

> I won't maintain an integration tree like John's wireless-testing,
> please continue to use his. If merge conflicts make it necessary, I'll
> resolve them in separate branches etc. and work it out with John.

So mac80211-next repo will stay on last stable release and not be
following the -rc releases?

> As a result, I ask you to not submit patch series that touch both your
> driver and the stack, please submit them independently. John will have
> to wait applying the patches to the driver until has has pulled in any
> dependencies via my trees.

This can become a hornets nest as it means more maintenance work for
John as the order of patches can change, eg. stack-dependent driver
patch is overtaken by patch for bugfix.

> If you maintain your own driver trees you're free to merge these trees
> if you need their contents, but please don't send my contents to John
> yourself, wait with your merge requests and nag me if you need me to
> push to John :-)

Although it may appeal to merge the trees, nagging for a upstream push
makes more sense.

> A word of caution though: I've not done this before, so while I think I
> know what I'm signing up for I'm sure I'll make mistakes. If you pull my
> tree in and I have to rebase due to those mistakes then would have to
> rebase as well, so maybe don't pull it tomorrow but give me some time to
> adjust to the workflow.

As stated I have some concerns, but let us see how it goes.

> Of course I'll continue to post my own patches to the mailing list well
> before I applying them.

Great plan ;-)

Gr. AvS

Re: [ANN] new wireless stack trees

[Johannes Berg]

On Thu, 2012-06-07 at 10:59 +0200, Arend van Spriel wrote:
> Although I can see the reason for maintaining the wireless stack
> separately from the wireless drivers, I would like to give my concerns
> about this idea.
> 
> While separating maintenance makes sense, moving to a separate
> repository impairs development in the wireless arena given the close
> relation between mac80211 stack and drivers and it will surely add
> latency. Integration between mac80211 and drivers will occur somewhat
> later and when issues are found in that area the fixes (at least
> mac80211 fixes) will add additional delay.

I'm not sure I share that concern much. We've always developed features
in mac80211 along with the driver, but once the mac80211 part is usable
it can be sent upstream without much concern for the driver. Even before
having my own trees we've always expected you to send patches for the
different components separately. The bigger change is that now John
could reject patches that don't apply because they're missing features,
so you may have to track mixed submissions more closely. I have a
feeling that's actually a good thing because the submitter can't just
fire & forget :-)

Technically of course you're right, there will be a little bit of a
delay between me deciding that I will apply your patch, applying it,
pushing it to John and then you sending your dependent patches. OTOH,
there always has been this delay because John always gave me plenty of
time to review mac80211 patches, so ultimately the delay might actually
go down if I merge quicker.

> > I won't maintain an integration tree like John's wireless-testing,
> > please continue to use his. If merge conflicts make it necessary, I'll
> > resolve them in separate branches etc. and work it out with John.
> 
> So mac80211-next repo will stay on last stable release and not be
> following the -rc releases?

No, it will follow wireless-next which is currently at 3.5-rc1. It will
probably stay there unless there's a reason to merge with something
else.

> > As a result, I ask you to not submit patch series that touch both your
> > driver and the stack, please submit them independently. John will have
> > to wait applying the patches to the driver until has has pulled in any
> > dependencies via my trees.
> 
> This can become a hornets nest as it means more maintenance work for
> John as the order of patches can change, eg. stack-dependent driver
> patch is overtaken by patch for bugfix.

If anything, it should mean more work for _you_, not John :-)
However, I don't see the problem here? This has always happened -- a new
stack-dependent driver feature will always be slower than a bugfix, by
the nature of the wireless/wireless-next trees.

johannes