John,
It appears that there's more trouble caused by my cfg80211 band API
patch than people are willing to put up with. Tomas has already asked
for it to be reverted, and neither Michael (Buesch) nor Stefano want to
maintain two driver branches (one "stable" 2.6.25 branch and one
"development" "for the future" branch).
FWIW, I support your decision to not push this particular patch for
2.6.25, it really doesn't fall into the "tested well enough to merge
during merge window" category.
Additionally, since Michael Wu has (privately) announced to stop working
on wireless, a number of drivers are effectively unmaintained now and
I'm not sure I can quickly fix the breakage that my patch probably
caused in those drivers, especially since Michael Wu is the only
developer with access to all that hardware.
To ease the short term pain, we can remove/revert the commits in
question (those being 51c4c94e89a2042e8b20d640b49b6b605d71420d,
6854a5291cce341751a7e2e195cc3e97d95afeec and
d0776155b288c20cc936bfd87d9a76255f244ed8).
Maybe I should have waited longer or posted the patches earlier. I
didn't post them earlier because I had not wanted to disrupt Intel's
iwlwifi work too much knowing that there were patches, and then those
patches caused bad breakage with my patch so I had to wait for another
Intel patchset fixing a number of bugs they introduced... I'll admit
that timing was horrible.
But, I'll be frank, if the patches are removed/revert I probably won't
continue maintaining them. I can't do much with these patches but
continually forward port them on top of new driver changes which is
boring and useless work. Experience has shown that hardly anybody but me
[1] actually tests my patches until I push them into your tree, so
continuing to forward port these patches won't actually help them become
better but can only make sure they don't completely bitrot into
oblivion.
The only way forward I see if these patches are reverted is that we
announce with the reversion that we'll merge them again in N weeks (with
N being a reasonably small number, say 4-6) and until then people can
test the patches and send me driver updates that I'll incorporate. But I
don't see how useful that is vs. just leaving the patches in place and
you managing the required driver updates.
johannes
[1] the only other people who test it seem to be mostly clueless people
who want to get AP mode working and then ask me stupid questions in
private... there are exceptions of course
Johannes Berg wrote:
> John,
>
> It appears that there's more trouble caused by my cfg80211 band API
> patch than people are willing to put up with. Tomas has already asked
> for it to be reverted, and neither Michael (Buesch) nor Stefano want to
> maintain two driver branches (one "stable" 2.6.25 branch and one
> "development" "for the future" branch).
>
> FWIW, I support your decision to not push this particular patch for
> 2.6.25, it really doesn't fall into the "tested well enough to merge
> during merge window" category.
>
> Additionally, since Michael Wu has (privately) announced to stop working
> on wireless, a number of drivers are effectively unmaintained now and
> I'm not sure I can quickly fix the breakage that my patch probably
> caused in those drivers, especially since Michael Wu is the only
> developer with access to all that hardware.
>
> To ease the short term pain, we can remove/revert the commits in
> question (those being 51c4c94e89a2042e8b20d640b49b6b605d71420d,
> 6854a5291cce341751a7e2e195cc3e97d95afeec and
> d0776155b288c20cc936bfd87d9a76255f244ed8).
>
> Maybe I should have waited longer or posted the patches earlier. I
> didn't post them earlier because I had not wanted to disrupt Intel's
> iwlwifi work too much knowing that there were patches, and then those
> patches caused bad breakage with my patch so I had to wait for another
> Intel patchset fixing a number of bugs they introduced... I'll admit
> that timing was horrible.
>
> But, I'll be frank, if the patches are removed/revert I probably won't
> continue maintaining them. I can't do much with these patches but
> continually forward port them on top of new driver changes which is
> boring and useless work. Experience has shown that hardly anybody but me
> [1] actually tests my patches until I push them into your tree, so
> continuing to forward port these patches won't actually help them become
> better but can only make sure they don't completely bitrot into
> oblivion.
>
> The only way forward I see if these patches are reverted is that we
> announce with the reversion that we'll merge them again in N weeks (with
> N being a reasonably small number, say 4-6) and until then people can
> test the patches and send me driver updates that I'll incorporate. But I
> don't see how useful that is vs. just leaving the patches in place and
> you managing the required driver updates.
>
> johannes
>
> [1] the only other people who test it seem to be mostly clueless people
> who want to get AP mode working and then ask me stupid questions in
> private... there are exceptions of course
>
Reverting the patch is not the answer. Everyone just needs to step up
and fix what they can. If maintainers are needed a call needs to be put
out to find one.
The work is in the direction that moves wireless in linux toward that of
a windows machine that the users want and need.
-Jory
On Jan 30, 2008 6:16 PM, Jory A. Pratt <[email protected]> wrote:
>
> Johannes Berg wrote:
> > John,
> >
> > It appears that there's more trouble caused by my cfg80211 band API
> > patch than people are willing to put up with. Tomas has already asked
> > for it to be reverted, and neither Michael (Buesch) nor Stefano want to
> > maintain two driver branches (one "stable" 2.6.25 branch and one
> > "development" "for the future" branch).
> >
> > FWIW, I support your decision to not push this particular patch for
> > 2.6.25, it really doesn't fall into the "tested well enough to merge
> > during merge window" category.
> >
> > Additionally, since Michael Wu has (privately) announced to stop working
> > on wireless, a number of drivers are effectively unmaintained now and
> > I'm not sure I can quickly fix the breakage that my patch probably
> > caused in those drivers, especially since Michael Wu is the only
> > developer with access to all that hardware.
> >
> > To ease the short term pain, we can remove/revert the commits in
> > question (those being 51c4c94e89a2042e8b20d640b49b6b605d71420d,
> > 6854a5291cce341751a7e2e195cc3e97d95afeec and
> > d0776155b288c20cc936bfd87d9a76255f244ed8).
> >
> > Maybe I should have waited longer or posted the patches earlier. I
> > didn't post them earlier because I had not wanted to disrupt Intel's
> > iwlwifi work too much knowing that there were patches, and then those
> > patches caused bad breakage with my patch so I had to wait for another
> > Intel patchset fixing a number of bugs they introduced... I'll admit
> > that timing was horrible.
> >
> > But, I'll be frank, if the patches are removed/revert I probably won't
> > continue maintaining them. I can't do much with these patches but
> > continually forward port them on top of new driver changes which is
> > boring and useless work. Experience has shown that hardly anybody but me
> > [1] actually tests my patches until I push them into your tree, so
> > continuing to forward port these patches won't actually help them become
> > better but can only make sure they don't completely bitrot into
> > oblivion.
> >
> > The only way forward I see if these patches are reverted is that we
> > announce with the reversion that we'll merge them again in N weeks (with
> > N being a reasonably small number, say 4-6) and until then people can
> > test the patches and send me driver updates that I'll incorporate. But I
> > don't see how useful that is vs. just leaving the patches in place and
> > you managing the required driver updates.
> >
> > johannes
> >
> > [1] the only other people who test it seem to be mostly clueless people
> > who want to get AP mode working and then ask me stupid questions in
> > private... there are exceptions of course
> >
> Reverting the patch is not the answer. Everyone just needs to step up
> and fix what they can. If maintainers are needed a call needs to be put
> out to find one.
> The work is in the direction that moves wireless in linux toward that of
> a windows machine that the users want and need.
Agree.
Just, the timing was unfortunate.
Tomas
> -Jory
>
On Wednesday 30 January 2008 16:52:31 Johannes Berg wrote:
> John,
>
> It appears that there's more trouble caused by my cfg80211 band API
> patch than people are willing to put up with. Tomas has already asked
> for it to be reverted, and neither Michael (Buesch) nor Stefano want to
> maintain two driver branches (one "stable" 2.6.25 branch and one
> "development" "for the future" branch).
No wait. I always supported that and will support that in the future.
But the problem I see with not merging this patch is that I think
it is _just_ wasted time in the end. If we simply merge it now we
can easily fix bugs in the huge merge window.
If we don't merge it, we are creating a branch of the driver. So
far no problem, really. But, if a bug appears that has to be fixed
differently for the old API and the new API, I'm not going to make
two patches. Simply because this could have beed avoided as a whole
by simply merging that patch _now_. I wish I had unlimited time to
port patches back. But I simply don't. So I am going to port patches
back that are needed, but not those for which we artificially created
the problems.
To say it again. I do support the concept of "stable" and "development"
branches. But I do not support artificial branching that is not needed
at all and can easily be avoided by simply applying that patch.
Just my 2ct.
--
Greetings Michael.
On Jan 30, 2008 11:25 AM, Tomas Winkler <[email protected]> wrote:
>
> On Jan 30, 2008 6:16 PM, Jory A. Pratt <[email protected]> wrote:
> >
> > Johannes Berg wrote:
> > > John,
> > >
> > > It appears that there's more trouble caused by my cfg80211 band API
> > > patch than people are willing to put up with. Tomas has already asked
> > > for it to be reverted, and neither Michael (Buesch) nor Stefano want to
> > > maintain two driver branches (one "stable" 2.6.25 branch and one
> > > "development" "for the future" branch).
> > >
> > > FWIW, I support your decision to not push this particular patch for
> > > 2.6.25, it really doesn't fall into the "tested well enough to merge
> > > during merge window" category.
> > >
> > > Additionally, since Michael Wu has (privately) announced to stop working
> > > on wireless, a number of drivers are effectively unmaintained now and
> > > I'm not sure I can quickly fix the breakage that my patch probably
> > > caused in those drivers, especially since Michael Wu is the only
> > > developer with access to all that hardware.
> > >
> > > To ease the short term pain, we can remove/revert the commits in
> > > question (those being 51c4c94e89a2042e8b20d640b49b6b605d71420d,
> > > 6854a5291cce341751a7e2e195cc3e97d95afeec and
> > > d0776155b288c20cc936bfd87d9a76255f244ed8).
> > >
> > > Maybe I should have waited longer or posted the patches earlier. I
> > > didn't post them earlier because I had not wanted to disrupt Intel's
> > > iwlwifi work too much knowing that there were patches, and then those
> > > patches caused bad breakage with my patch so I had to wait for another
> > > Intel patchset fixing a number of bugs they introduced... I'll admit
> > > that timing was horrible.
> > >
> > > But, I'll be frank, if the patches are removed/revert I probably won't
> > > continue maintaining them. I can't do much with these patches but
> > > continually forward port them on top of new driver changes which is
> > > boring and useless work. Experience has shown that hardly anybody but me
> > > [1] actually tests my patches until I push them into your tree, so
> > > continuing to forward port these patches won't actually help them become
> > > better but can only make sure they don't completely bitrot into
> > > oblivion.
> > >
> > > The only way forward I see if these patches are reverted is that we
> > > announce with the reversion that we'll merge them again in N weeks (with
> > > N being a reasonably small number, say 4-6) and until then people can
> > > test the patches and send me driver updates that I'll incorporate. But I
> > > don't see how useful that is vs. just leaving the patches in place and
> > > you managing the required driver updates.
> > >
> > > johannes
> > >
> > > [1] the only other people who test it seem to be mostly clueless people
> > > who want to get AP mode working and then ask me stupid questions in
> > > private... there are exceptions of course
> > >
> > Reverting the patch is not the answer. Everyone just needs to step up
> > and fix what they can. If maintainers are needed a call needs to be put
> > out to find one.
> > The work is in the direction that moves wireless in linux toward that of
> > a windows machine that the users want and need.
>
> Agree.
> Just, the timing was unfortunate.
Please keep. The question then becomes if we should push for the merge window.
Luis