Greetings,
So I'm tired of a) being asked how wireless-testing is managed; and,
b) having trouble explaining it. I think it is time to move to a
more conventional process for wireless patches.
The main change I would like to make for now is to move wireless-2.6
and wireless-next-2.6 to a default "immutable history" policy.
By this I mean that I will strive to keep the history both clean
and immutable in those trees. If for some reason I can't make that
happen and have to rebase those trees, I will make a loud and obvious
announcement on the linux-wireless mailing list. More likely, it
means I may have to push an occasional revert through those trees
that I might have otherwise avoided.
One of the ramifications of this will be that I will need to be
extra careful about what gets merged into those trees. I have been
pushing patches into those trees quickly after merging them into
wireless-testing, relying on linux-next to uncover some of the problems
a quick review might miss. Now I will need to have higher confidence
in a patch before pushing it to wireless-next-2.6 or (especially)
wireless-2.6, so some patches may take longer to get there. All of
your usual dilligent reviews are most helpful in this regard.
For now, the main change to wireless-testing will be that I will be
pulling from wireless-2.6 and wireless-next-2.6 rather than reapplying
most patches. This should limit (and possibly eliminate) the confusing
patch-revert-reapply-repeat practice I have been using there for a
long time. However, I still anticipate using w-t as a holding area
for questionable patches. So, at least some patches may still get
the revert-reapply treatment. I may ask Stephen to pull w-t into
linux-next in order to expand testing of any such patches.
One advantage to this new process is that it will enable me to more
readily accept actual git pull requests from driver/subsystem
maintainers. In order for this to work, those maintainers will need to
send separate pull requests for fixes intended for the current release
and for features intended for the next release. They will also need to
maintain their trees appropriately (i.e. separate trees or separate
branches with appropriate bases) for this to work. If anyone is
interested in doing this, feel free to ask more questions.
Well, there is my overview. Anyone have questions/objections/etc?
Thanks,
John
P.S. If you care (and most of you should not), I intend for
wireless-2.6 and wireless-next-2.6 to pull from Linus at v2.6.33-rc1
and then only pull from net-2.6 or net-next-2.6 (or wireless-2.6)
if necessary for dependencies or conflict resolution. Any
driver/subsystem maintainers that want me to pull from them should
consider doing something similar.
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon, 14 Dec 2009 17:20:11 +0100
> Well, in theory all maintainers should be testing -next kernels
> so nothing should change also in this regard.
You conveniently did not quote and respond to my comments showing that
you can ask git tools to seperate out the changesets for you, regardless
of what subsystem maintainers decide to do.
Power is in your hands, really. :-)
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
>>> <[email protected]> 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: [email protected]" 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
[email protected] might be all we have. Be ready.
On Monday 14 December 2009 07:41:24 pm David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Mon, 14 Dec 2009 19:24:47 +0100
>
> > On Monday 14 December 2009 07:03:45 pm David Miller wrote:
> >> From: Bartlomiej Zolnierkiewicz <[email protected]>
> >> Date: Mon, 14 Dec 2009 17:20:11 +0100
> >>
> >> > Well, in theory all maintainers should be testing -next kernels
> >> > so nothing should change also in this regard.
> >>
> >> You conveniently did not quote and respond to my comments showing that
> >> you can ask git tools to seperate out the changesets for you, regardless
> >> of what subsystem maintainers decide to do.
> >>
> >> Power is in your hands, really. :-)
> >
> > That is simply untrue from Linus' kernel point of view.
> >
> > Each networking merge contains multiple sub-merges from wireless tree
> > (at random points in networking tree history) which in turn may contain
> > multiple sub-merges from Johannes (at random points in wireless tree
> > history) and wireless driver sub-projects so unless you are a hardcore
> > networking/wireless developer it is practically impossible to make
> > a sense out of it in a reasonable time.
>
> That's not true. I use "gitk -- net/mac80211" all the time and it's
> helped me find bugs. Or try "gitk -- include/tcp* net/ipv4/tcp*" to
> hunt down TCP regressions, etc.
It helps but with more complex ones you're back to guesswork and applying
by hand fixes for already fixed ages ago in-the-middle regressions.
However that's not the main point here.
With almost all other major trees I'm able to stay more-or-less informed on
what is being merged to Linus tree and follow the development thanks to well
fine-grained pull requests (up to few hundred commit in one go, very often
accompanied by combined diff).
The networking is unfortunate exception with thousands of commits in one go,
i.e. for 2.6.33 "merge window" it was 1815 (!) commits:
commit d7fc02c7bae7b1cf69269992cf880a43a350cdaa
Merge: ee1262d 28b4d5c
Author: Linus Torvalds <[email protected]>
Date: Tue Dec 8 07:55:01 2009 -0800
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1815 commits)
with completely insane amount of changes:
1396 files changed, 113877 insertions(+), 71108 deletions(-)
You may say that I should be following the development as it happens but such
strict requirement is not present in any other kernel subsystem tree.
--
Bartlomiej Zolnierkiewicz
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
> <[email protected]> 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: [email protected]" 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.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Thu, Dec 10, 2009 at 6:37 AM, John W. Linville
<[email protected]> wrote:
> On Thu, Dec 10, 2009 at 06:31:02AM -0800, Luis R. Rodriguez wrote:
>> On Thu, Dec 10, 2009 at 6:04 AM, Kalle Valo <[email protected]> wrote:
>> > "John W. Linville" <[email protected]> writes:
>> >
>> >> I still see value in a tree that has a reasonably stable base and
>> >> contains both wireless fixes and wireless features.
>> >
>> > I agree, it makes things a lot easier.
>> >
>> >> So, I think wireless-testing remains as the focal point for wireless
>> >> LAN testing and development. I'll just be getting patches there in a
>> >> slightly different process.
>> >
>> > Sounds very good. So I'll continue using wireless-testing. Thanks.
>>
>> But we use wireless-next as base though if we want to send you pull
>> requests, ay?
>
> Yes, that is correct -- people that want to send patches (or simply
> test) should use wireless-testing. People that want to send pull
> requests need to have trees based on wireless-2.6 (for fixes)
Typically we have relied on you to push fixes into wireless-2.6, does
this change a bit now in that we should try to keep better track of
stable fixes and send them to you instead if we're doing the pull
request method?
> and/or
> wireless-next-2.6 (for features). If you are sending pull requests
> and have a feature that depends on a fix then we'll have to coordinate
> to make sure the right bits get into the right trees.
OK, got it.
Luis
On Thu, Dec 10, 2009 at 6:04 AM, Kalle Valo <[email protected]> wrote:
> "John W. Linville" <[email protected]> writes:
>
>> I still see value in a tree that has a reasonably stable base and
>> contains both wireless fixes and wireless features.
>
> I agree, it makes things a lot easier.
>
>> So, I think wireless-testing remains as the focal point for wireless
>> LAN testing and development. I'll just be getting patches there in a
>> slightly different process.
>
> Sounds very good. So I'll continue using wireless-testing. Thanks.
But we use wireless-next as base though if we want to send you pull
requests, ay?
Luis
On Monday 14 December 2009 08:46:52 pm David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Mon, 14 Dec 2009 20:42:13 +0100
>
> > However looking at "Top non-author signoffs in 2.6.31" [1]:
> >
> > David S. Miller 964 10.1%
> > Ingo Molnar 948 9.9%
> > Greg Kroah-Hartman 582 6.1%
> > ...
> >
> > it seems that there are people able to do large upstream merges in much
> > more transparent and reviewer-friendly way so it is not like there exists
> > some real physical barrier for not even trying to do things better..
>
> Greg (USB, staging) and Ingo (scheduler, perf, tracing, x86) each work
> in several disconnected areas, and have you seen the size of the
I would risk saying that in Ingo's case those areas are frequently more
inter-connected than i.e. wireless driver changes and core networking ones...
> staging tree merges? :-)
..and yes, I did take a look at 2.6.33 staging merge before writing my mail.
I think that it was too big personally but it was still only 235 commits:
commit 0e2f7b837600979d5b6f174a6ff695b85942e985
Merge: f58df54 032fec3
Author: Linus Torvalds <[email protected]>
Date: Fri Dec 11 15:25:56 2009 -0800
Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (235 commits)
1815 networking commits means almost 8x more and while LOC amount for staging
is much higher, networking changes affect 2x more files.
--
Bartlomiej Zolnierkiewicz
On Monday 14 December 2009 04:19:17 pm David Miller wrote:
> From: "John W. Linville" <[email protected]>
> Date: Mon, 14 Dec 2009 09:26:02 -0500
>
> > On Mon, Dec 14, 2009 at 03:16:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> >
> >> Now if only somebody could come up with a way to split 'monstermerges'
> >> for Linus tree into something more fine-grained (thousands of commits in
> >> a single merge is too much for anyone not directly involved into current
> >> networking developments IMHO) I would be completely satisfied. ;)
> >
> > You'll have to talk to Dave about that one, although FWIW I'm not
> > sure how to prevent that with the current "merge window" policy...
>
> Well, the merge window event does not exist in a vacuum.
>
> Development is happening all during this time and checking the
> subsystem trees of interest to you every week or so will do wonders to
> your sanity. :-)
The problem is that repeating this for every subsystem tree out there does
indeed wonders to ones (in)sanity. :)
--
Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon, 14 Dec 2009 15:59:29 +0100
> Hmmm, there are multiple ideas to investigate even within the current
> "merge window" policy. Decoupling driver trees from core changes should
> certainly be possible (it works just fine in the storage area), some
> architectures make heavy use of topic branches to prevent 'monstermerge'
> issue etc.
I don't think seperating drivers out will help.
I'd say every 5 or core changes we get one that ends up touching some
API and a hand full of drivers.
And this also has implications for testing. I want the most
active driver folks have to test their stuff against the core
changes as well.
This all happens automatically.
You can always tell git tools to just give you net/ changes.
On Monday 14 December 2009 03:26:02 pm John W. Linville wrote:
> On Mon, Dec 14, 2009 at 03:16:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> > Now if only somebody could come up with a way to split 'monstermerges'
> > for Linus tree into something more fine-grained (thousands of commits in
> > a single merge is too much for anyone not directly involved into current
> > networking developments IMHO) I would be completely satisfied. ;)
>
> You'll have to talk to Dave about that one, although FWIW I'm not
Yep, it was directed at him (since he was on cc: already).
> sure how to prevent that with the current "merge window" policy...
Hmmm, there are multiple ideas to investigate even within the current
"merge window" policy. Decoupling driver trees from core changes should
certainly be possible (it works just fine in the storage area), some
architectures make heavy use of topic branches to prevent 'monstermerge'
issue etc.
Anyway this is just some food for thought for Dave once he finds some
time away from his usual more high-priority activities.. ;)
--
Bartlomiej Zolnierkiewicz
From: Luciano Coelho <[email protected]>
Date: Mon, 14 Dec 2009 14:32:35 +0200
> 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.
No you won't need to rebase, that's the last thing you should do.
When there is a conflict to resolve or a situation like the one you
describe, you simply pull John's tree into your's.
On Monday 14 December 2009 07:03:45 pm David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Mon, 14 Dec 2009 17:20:11 +0100
>
> > Well, in theory all maintainers should be testing -next kernels
> > so nothing should change also in this regard.
>
> You conveniently did not quote and respond to my comments showing that
> you can ask git tools to seperate out the changesets for you, regardless
> of what subsystem maintainers decide to do.
>
> Power is in your hands, really. :-)
That is simply untrue from Linus' kernel point of view.
Each networking merge contains multiple sub-merges from wireless tree
(at random points in networking tree history) which in turn may contain
multiple sub-merges from Johannes (at random points in wireless tree
history) and wireless driver sub-projects so unless you are a hardcore
networking/wireless developer it is practically impossible to make
a sense out of it in a reasonable time.
--
Bartlomiej Zolnierkiewicz
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
>> <[email protected]> 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: [email protected]" 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.
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon, 14 Dec 2009 20:16:00 +0100
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon, 14 Dec 2009 20:16:00 +0100
> On Monday 14 December 2009 07:41:24 pm David Miller wrote:
>> That's not true. I use "gitk -- net/mac80211" all the time and it's
>> helped me find bugs. Or try "gitk -- include/tcp* net/ipv4/tcp*" to
>> hunt down TCP regressions, etc.
>
> It helps but with more complex ones you're back to guesswork and applying
> by hand fixes for already fixed ages ago in-the-middle regressions.
Examples?
> commit d7fc02c7bae7b1cf69269992cf880a43a350cdaa
> Merge: ee1262d 28b4d5c
> Author: Linus Torvalds <[email protected]>
> Date: Tue Dec 8 07:55:01 2009 -0800
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>
> * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1815 commits)
>
> with completely insane amount of changes:
>
> 1396 files changed, 113877 insertions(+), 71108 deletions(-)
>
> You may say that I should be following the development as it happens but such
> strict requirement is not present in any other kernel subsystem tree.
About 1400 is drivers/net and about 500 is net
It's going to be a lot of changes no matter how I or John split it
up.
And guess what's just-as if not even more important? A unified tree
makes things easier for me. So unless you plan on applying 100
patches a day for me and doing all the cross merges, that's how I plan
to keep doing things :-)
On Mon, Dec 14, 2009 at 03:16:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Now if only somebody could come up with a way to split 'monstermerges'
> for Linus tree into something more fine-grained (thousands of commits in
> a single merge is too much for anyone not directly involved into current
> networking developments IMHO) I would be completely satisfied. ;)
You'll have to talk to Dave about that one, although FWIW I'm not
sure how to prevent that with the current "merge window" policy...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
"John W. Linville" <[email protected]> writes:
> I still see value in a tree that has a reasonably stable base and
> contains both wireless fixes and wireless features.
I agree, it makes things a lot easier.
> So, I think wireless-testing remains as the focal point for wireless
> LAN testing and development. I'll just be getting patches there in a
> slightly different process.
Sounds very good. So I'll continue using wireless-testing. Thanks.
--
Kalle Valo
From: "John W. Linville" <[email protected]>
Date: Wed, 9 Dec 2009 16:10:55 -0500
> P.S. If you care (and most of you should not), I intend for
> wireless-2.6 and wireless-next-2.6 to pull from Linus at v2.6.33-rc1
> and then only pull from net-2.6 or net-next-2.6 (or wireless-2.6)
> if necessary for dependencies or conflict resolution. Any
> driver/subsystem maintainers that want me to pull from them should
> consider doing something similar.
Totally awesome, now you'll be doing merges for me too :-)
On Wednesday 09 December 2009 10:10:55 pm John W. Linville wrote:
> Greetings,
>
> So I'm tired of a) being asked how wireless-testing is managed; and,
> b) having trouble explaining it. I think it is time to move to a
> more conventional process for wireless patches.
>
> The main change I would like to make for now is to move wireless-2.6
> and wireless-next-2.6 to a default "immutable history" policy.
> By this I mean that I will strive to keep the history both clean
> and immutable in those trees. If for some reason I can't make that
> happen and have to rebase those trees, I will make a loud and obvious
> announcement on the linux-wireless mailing list. More likely, it
> means I may have to push an occasional revert through those trees
> that I might have otherwise avoided.
>
> One of the ramifications of this will be that I will need to be
> extra careful about what gets merged into those trees. I have been
> pushing patches into those trees quickly after merging them into
> wireless-testing, relying on linux-next to uncover some of the problems
> a quick review might miss. Now I will need to have higher confidence
> in a patch before pushing it to wireless-next-2.6 or (especially)
> wireless-2.6, so some patches may take longer to get there. All of
> your usual dilligent reviews are most helpful in this regard.
>
> For now, the main change to wireless-testing will be that I will be
> pulling from wireless-2.6 and wireless-next-2.6 rather than reapplying
> most patches. This should limit (and possibly eliminate) the confusing
> patch-revert-reapply-repeat practice I have been using there for a
> long time. However, I still anticipate using w-t as a holding area
> for questionable patches. So, at least some patches may still get
> the revert-reapply treatment. I may ask Stephen to pull w-t into
> linux-next in order to expand testing of any such patches.
>
> One advantage to this new process is that it will enable me to more
> readily accept actual git pull requests from driver/subsystem
> maintainers. In order for this to work, those maintainers will need to
> send separate pull requests for fixes intended for the current release
> and for features intended for the next release. They will also need to
> maintain their trees appropriately (i.e. separate trees or separate
> branches with appropriate bases) for this to work. If anyone is
> interested in doing this, feel free to ask more questions.
>
> Well, there is my overview. Anyone have questions/objections/etc?
Thanks John! This sounds great (especially w-t part) and addresses large
part of my past concerns regarding wireless/networking trees.
Now if only somebody could come up with a way to split 'monstermerges'
for Linus tree into something more fine-grained (thousands of commits in
a single merge is too much for anyone not directly involved into current
networking developments IMHO) I would be completely satisfied. ;)
--
Bartlomiej Zolnierkiewicz
On Thu, Dec 10, 2009 at 03:38:38PM +0200, Kalle Valo wrote:
> "John W. Linville" <[email protected]> writes:
>
> > Greetings,
>
> Hi,
>
> > So I'm tired of a) being asked how wireless-testing is managed; and,
> > b) having trouble explaining it. I think it is time to move to a
> > more conventional process for wireless patches.
>
> Hopefully this also reduces your workload. There is quite a lot of
> wireless patches floating around nowadays.
>
> > More likely, it means I may have to push an occasional revert
> > through those trees that I might have otherwise avoided.
>
> Having reverts in the tree doesn't sound that bad. Even we do mistakes
> sometimes, no need to hide them :)
>
> > For now, the main change to wireless-testing will be that I will be
> > pulling from wireless-2.6 and wireless-next-2.6 rather than reapplying
> > most patches. This should limit (and possibly eliminate) the confusing
> > patch-revert-reapply-repeat practice I have been using there for a
> > long time. However, I still anticipate using w-t as a holding area
> > for questionable patches. So, at least some patches may still get
> > the revert-reapply treatment. I may ask Stephen to pull w-t into
> > linux-next in order to expand testing of any such patches.
>
> I have two questions:
>
> What tree should I base my patches on?
>
> What about testing? Which tree is best to use for testing latest and
> greatest wireless patches?
I still see value in a tree that has a reasonably stable base and
contains both wireless fixes and wireless features. So, I think
wireless-testing remains as the focal point for wireless LAN testing
and development. I'll just be getting patches there in a slightly
different process.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
From: "John W. Linville" <[email protected]>
Date: Mon, 14 Dec 2009 09:26:02 -0500
> On Mon, Dec 14, 2009 at 03:16:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
>> Now if only somebody could come up with a way to split 'monstermerges'
>> for Linus tree into something more fine-grained (thousands of commits in
>> a single merge is too much for anyone not directly involved into current
>> networking developments IMHO) I would be completely satisfied. ;)
>
> You'll have to talk to Dave about that one, although FWIW I'm not
> sure how to prevent that with the current "merge window" policy...
Well, the merge window event does not exist in a vacuum.
Development is happening all during this time and checking the
subsystem trees of interest to you every week or so will do wonders to
your sanity. :-)
And you should be looking often anyways so that nothing comes as a
surprise once the merge window actually happens. Things need to be
discovered and sorted long before then.
On Thu, Dec 10, 2009 at 06:53:43AM -0800, Luis R. Rodriguez wrote:
> On Thu, Dec 10, 2009 at 6:37 AM, John W. Linville
> <[email protected]> wrote:
> > On Thu, Dec 10, 2009 at 06:31:02AM -0800, Luis R. Rodriguez wrote:
> >> On Thu, Dec 10, 2009 at 6:04 AM, Kalle Valo <[email protected]> wrote:
> >> > "John W. Linville" <[email protected]> writes:
> >> >
> >> >> I still see value in a tree that has a reasonably stable base and
> >> >> contains both wireless fixes and wireless features.
> >> >
> >> > I agree, it makes things a lot easier.
> >> >
> >> >> So, I think wireless-testing remains as the focal point for wireless
> >> >> LAN testing and development. I'll just be getting patches there in a
> >> >> slightly different process.
> >> >
> >> > Sounds very good. So I'll continue using wireless-testing. Thanks.
> >>
> >> But we use wireless-next as base though if we want to send you pull
> >> requests, ay?
> >
> > Yes, that is correct -- people that want to send patches (or simply
> > test) should use wireless-testing. ?People that want to send pull
> > requests need to have trees based on wireless-2.6 (for fixes)
>
> Typically we have relied on you to push fixes into wireless-2.6, does
> this change a bit now in that we should try to keep better track of
> stable fixes and send them to you instead if we're doing the pull
> request method?
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: [email protected]" to commit logs as appropriate.
The whole point of the pulls is to keep me from having to touch
the patches.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Thu, Dec 10, 2009 at 06:31:02AM -0800, Luis R. Rodriguez wrote:
> On Thu, Dec 10, 2009 at 6:04 AM, Kalle Valo <[email protected]> wrote:
> > "John W. Linville" <[email protected]> writes:
> >
> >> I still see value in a tree that has a reasonably stable base and
> >> contains both wireless fixes and wireless features.
> >
> > I agree, it makes things a lot easier.
> >
> >> So, I think wireless-testing remains as the focal point for wireless
> >> LAN testing and development. I'll just be getting patches there in a
> >> slightly different process.
> >
> > Sounds very good. So I'll continue using wireless-testing. Thanks.
>
> But we use wireless-next as base though if we want to send you pull
> requests, ay?
Yes, that is correct -- people that want to send patches (or simply
test) should use wireless-testing. People that want to send pull
requests need to have trees based on wireless-2.6 (for fixes) and/or
wireless-next-2.6 (for features). If you are sending pull requests
and have a feature that depends on a fix then we'll have to coordinate
to make sure the right bits get into the right trees.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon, 14 Dec 2009 19:24:47 +0100
> On Monday 14 December 2009 07:03:45 pm David Miller wrote:
>> From: Bartlomiej Zolnierkiewicz <[email protected]>
>> Date: Mon, 14 Dec 2009 17:20:11 +0100
>>
>> > Well, in theory all maintainers should be testing -next kernels
>> > so nothing should change also in this regard.
>>
>> You conveniently did not quote and respond to my comments showing that
>> you can ask git tools to seperate out the changesets for you, regardless
>> of what subsystem maintainers decide to do.
>>
>> Power is in your hands, really. :-)
>
> That is simply untrue from Linus' kernel point of view.
>
> Each networking merge contains multiple sub-merges from wireless tree
> (at random points in networking tree history) which in turn may contain
> multiple sub-merges from Johannes (at random points in wireless tree
> history) and wireless driver sub-projects so unless you are a hardcore
> networking/wireless developer it is practically impossible to make
> a sense out of it in a reasonable time.
That's not true. I use "gitk -- net/mac80211" all the time and it's
helped me find bugs. Or try "gitk -- include/tcp* net/ipv4/tcp*" to
hunt down TCP regressions, etc.
You can ignore the merge changesets, they are largely John and
myself sorting out conflicts between two bodies of work, and
concentrate only on the real commits in there that touch those
directories.
From: Bartlomiej Zolnierkiewicz <[email protected]>
Date: Mon, 14 Dec 2009 20:42:13 +0100
> However looking at "Top non-author signoffs in 2.6.31" [1]:
>
> David S. Miller 964 10.1%
> Ingo Molnar 948 9.9%
> Greg Kroah-Hartman 582 6.1%
> ...
>
> it seems that there are people able to do large upstream merges in much
> more transparent and reviewer-friendly way so it is not like there exists
> some real physical barrier for not even trying to do things better..
Greg (USB, staging) and Ingo (scheduler, perf, tracing, x86) each work
in several disconnected areas, and have you seen the size of the
staging tree merges? :-)
On Monday 14 December 2009 08:23:04 pm David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Mon, 14 Dec 2009 20:16:00 +0100
>
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Mon, 14 Dec 2009 20:16:00 +0100
>
> > On Monday 14 December 2009 07:41:24 pm David Miller wrote:
> >> That's not true. I use "gitk -- net/mac80211" all the time and it's
> >> helped me find bugs. Or try "gitk -- include/tcp* net/ipv4/tcp*" to
> >> hunt down TCP regressions, etc.
> >
> > It helps but with more complex ones you're back to guesswork and applying
> > by hand fixes for already fixed ages ago in-the-middle regressions.
>
> Examples?
>
> > commit d7fc02c7bae7b1cf69269992cf880a43a350cdaa
> > Merge: ee1262d 28b4d5c
> > Author: Linus Torvalds <[email protected]>
> > Date: Tue Dec 8 07:55:01 2009 -0800
> >
> > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
> >
> > * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1815 commits)
> >
> > with completely insane amount of changes:
> >
> > 1396 files changed, 113877 insertions(+), 71108 deletions(-)
> >
> > You may say that I should be following the development as it happens but such
> > strict requirement is not present in any other kernel subsystem tree.
>
> About 1400 is drivers/net and about 500 is net
>
> It's going to be a lot of changes no matter how I or John split it
> up.
The problem is not the total number of changes but their amount in one go.
> And guess what's just-as if not even more important? A unified tree
> makes things easier for me. So unless you plan on applying 100
[ 100 patches a day? The math doesn't add up...? ]
> patches a day for me and doing all the cross merges, that's how I plan
> to keep doing things :-)
Oh, feel free to do what works best for you. :)
However looking at "Top non-author signoffs in 2.6.31" [1]:
David S. Miller 964 10.1%
Ingo Molnar 948 9.9%
Greg Kroah-Hartman 582 6.1%
...
it seems that there are people able to do large upstream merges in much
more transparent and reviewer-friendly way so it is not like there exists
some real physical barrier for not even trying to do things better..
[1] http://lwn.net/Articles/348445/
--
Bartlomiej Zolnierkiewicz
On Monday 14 December 2009 04:23:23 pm David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Date: Mon, 14 Dec 2009 15:59:29 +0100
>
> > Hmmm, there are multiple ideas to investigate even within the current
> > "merge window" policy. Decoupling driver trees from core changes should
> > certainly be possible (it works just fine in the storage area), some
> > architectures make heavy use of topic branches to prevent 'monstermerge'
> > issue etc.
>
> I don't think seperating drivers out will help.
>
> I'd say every 5 or core changes we get one that ends up touching some
> API and a hand full of drivers.
Not a problem, driver trees may be based on core tree.
> And this also has implications for testing. I want the most
> active driver folks have to test their stuff against the core
> changes as well.
>
> This all happens automatically.
Well, in theory all maintainers should be testing -next kernels
so nothing should change also in this regard.
--
Bartlomiej Zolnierkiewicz
On Thu, Dec 10, 2009 at 7:03 AM, John W. Linville
<[email protected]> wrote:
> On Thu, Dec 10, 2009 at 06:53:43AM -0800, Luis R. Rodriguez wrote:
>> On Thu, Dec 10, 2009 at 6:37 AM, John W. Linville
>> <[email protected]> wrote:
>> > On Thu, Dec 10, 2009 at 06:31:02AM -0800, Luis R. Rodriguez wrote:
>> >> On Thu, Dec 10, 2009 at 6:04 AM, Kalle Valo <[email protected]> wrote:
>> >> > "John W. Linville" <[email protected]> writes:
>> >> >
>> >> >> I still see value in a tree that has a reasonably stable base and
>> >> >> contains both wireless fixes and wireless features.
>> >> >
>> >> > I agree, it makes things a lot easier.
>> >> >
>> >> >> So, I think wireless-testing remains as the focal point for wireless
>> >> >> LAN testing and development. I'll just be getting patches there in a
>> >> >> slightly different process.
>> >> >
>> >> > Sounds very good. So I'll continue using wireless-testing. Thanks.
>> >>
>> >> But we use wireless-next as base though if we want to send you pull
>> >> requests, ay?
>> >
>> > Yes, that is correct -- people that want to send patches (or simply
>> > test) should use wireless-testing. People that want to send pull
>> > requests need to have trees based on wireless-2.6 (for fixes)
>>
>> Typically we have relied on you to push fixes into wireless-2.6, does
>> this change a bit now in that we should try to keep better track of
>> stable fixes and send them to you instead if we're doing the pull
>> request method?
>
> 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: [email protected]" 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.
Luis
"John W. Linville" <[email protected]> writes:
> Greetings,
Hi,
> So I'm tired of a) being asked how wireless-testing is managed; and,
> b) having trouble explaining it. I think it is time to move to a
> more conventional process for wireless patches.
Hopefully this also reduces your workload. There is quite a lot of
wireless patches floating around nowadays.
> More likely, it means I may have to push an occasional revert
> through those trees that I might have otherwise avoided.
Having reverts in the tree doesn't sound that bad. Even we do mistakes
sometimes, no need to hide them :)
> For now, the main change to wireless-testing will be that I will be
> pulling from wireless-2.6 and wireless-next-2.6 rather than reapplying
> most patches. This should limit (and possibly eliminate) the confusing
> patch-revert-reapply-repeat practice I have been using there for a
> long time. However, I still anticipate using w-t as a holding area
> for questionable patches. So, at least some patches may still get
> the revert-reapply treatment. I may ask Stephen to pull w-t into
> linux-next in order to expand testing of any such patches.
I have two questions:
What tree should I base my patches on?
What about testing? Which tree is best to use for testing latest and
greatest wireless patches?
--
Kalle Valo