* Re: bisecting with wireless-testing
[not found] ` <20090819175809.GD5905@tuxdriver.com>
@ 2009-08-19 18:34 ` Luis R. Rodriguez
2009-08-19 18:44 ` John W. Linville
0 siblings, 1 reply; 2+ messages in thread
From: Luis R. Rodriguez @ 2009-08-19 18:34 UTC (permalink / raw)
To: John W. Linville
Cc: Luis Rodriguez, Pavel Roskin, Luis R. Rodriguez, ath9k-devel,
linux-wireless
Renaming subject and adding linux-wireless.
On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:
> On Tue, Aug 18, 2009 at 02:57:48PM -0700, Luis R. Rodriguez wrote:
> > On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote:
> > > On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
> > >
> > > > > Anyway, why is it better for bisecting?
Just for reference for linux-wireles readers here I had indicated
wireless-next-2.6 was better for bisecting than wireless-testing.
> > > >
> > > > Because to help developers not have to do:
> > > >
> > > > git branch -m poo
> > > > git checkout -b master origin/master
> > > > # Then apply patches manually
> > > >
> > > > Instead of the better rebasing:
> > > >
> > > > git branch -m save-my-stuff
> > > > git checkout -b master origin/master
> > > > git checkout save-my-stuff
> > > > git rebase master
> > >
> > > I use STGit, so perhaps I miss all that fun. I have never had any
> > > trouble tracking wireless-testing while keeping my patches.
> >
> > Oh this was a long time ago, pre ath5k I think.
> >
> > > > john reverts his patches on wireless-testing before rebasing to Linus'
> > > > tree. There may be some other added benefit other than helping us
> > > > rebase cleanly, not sure. But I do remember before that I never was
> > > > able to rebase my patches, and now rebasing works quite nicely.
> > >
> > > You mean it's better to track wireless-next-2.6 for those of us trying
> > > to stay on top of the wireless development?
> >
> > No, not at all, I meant wireless-next-2.6 is best for bisecting.
> >
> > wireless-testing is indeed the place to look at for development.
> >
> > > I must have missed the
> > > memo.
> >
> > I don't think we ever really publized this much, because technically
> > the reverting won't happen unless John rebases and typically between
> > rebases to a next RC kernel you *could* technically bisect an issue.
> > But not all the times.
> >
> > > Indeed, wireless-next-2.6 has a couple of commits that
> > > wireless-testing doesn't have yet.
> > >
> > > I agree that having to bisect through reverts is not fun, and it takes
> > > one or two extra iterations.
> >
> > Right, which is why I wanted to mention it, will extend the info on
> > the wiki on the development section once John ACKs/NACKs this.
>
> It should not be necessary to bisect through reverts. I maintain
> different tags for such purposes.
>
> Always use the lastest merge-* tag as the base for bisection.
> This should be equivalent to whichever -rc release from Linus is the
> current base for wireless-testing. If you need to go any earlier
> than that, you should be using linux-2.6.
>
> So for example with current tree:
>
> git bisect start
> git bisect bad master-2009-08-19
> git bisect good merge-2009-08-14
>
> This should include all of the current wireless patches in
> wireless-testing but not in the base linux-2.6 kernel.
This does indeed help alot. Just to be clear let me provide an
example. So say git tag -l | grep merge | tail -3 yields:
merge-2009-07-24
merge-2009-08-03
merge-2009-08-14
I believe what you are indicating if you are bisecting using to avoid
running into the reverts you'd have to ensure then that you bisect between
a bad commit and the next dated merge tag. So if you ran into a snag say
on master-2009-08-06, you should test if merge-2009-08-03 is good first,
and if its not then consider using linux-2.6.git ? If so wouldn't
the code on master-2009-08-06 not yet be available on linux-2.6.git?
> I haven't tracked-down this thread in the archives...am I addressing
> the issue correctly?
Indeed! Thanks a lot.
Luis
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: bisecting with wireless-testing
2009-08-19 18:34 ` bisecting with wireless-testing Luis R. Rodriguez
@ 2009-08-19 18:44 ` John W. Linville
0 siblings, 0 replies; 2+ messages in thread
From: John W. Linville @ 2009-08-19 18:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Pavel Roskin, Luis R. Rodriguez, ath9k-devel,
linux-wireless
On Wed, Aug 19, 2009 at 11:34:16AM -0700, Luis R. Rodriguez wrote:
> Renaming subject and adding linux-wireless.
>
> On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:
> > It should not be necessary to bisect through reverts. I maintain
> > different tags for such purposes.
> >
> > Always use the lastest merge-* tag as the base for bisection.
> > This should be equivalent to whichever -rc release from Linus is the
> > current base for wireless-testing. If you need to go any earlier
> > than that, you should be using linux-2.6.
> >
> > So for example with current tree:
> >
> > git bisect start
> > git bisect bad master-2009-08-19
> > git bisect good merge-2009-08-14
> >
> > This should include all of the current wireless patches in
> > wireless-testing but not in the base linux-2.6 kernel.
>
> This does indeed help alot. Just to be clear let me provide an
> example. So say git tag -l | grep merge | tail -3 yields:
>
> merge-2009-07-24
> merge-2009-08-03
> merge-2009-08-14
>
> I believe what you are indicating if you are bisecting using to avoid
> running into the reverts you'd have to ensure then that you bisect between
> a bad commit and the next dated merge tag. So if you ran into a snag say
> on master-2009-08-06, you should test if merge-2009-08-03 is good first,
> and if its not then consider using linux-2.6.git ? If so wouldn't
> the code on master-2009-08-06 not yet be available on linux-2.6.git?
If you look, merge-2009-08-03 is identical to 2.6.31-rc5:
git diff merge-2009-08-03..v2.6.31-rc5
So if you have a problem in master-2009-08-06, then either the
problem exists in v2.6.31-rc5 or it is between merge-2009-08-03 and
master-2009-08-06. (Read the tags carefully, they look similar.)
The point is, it never makes sense to use a good marker any
farther back than the most recent merge-* tag when trying to bisect
wireless-testing. Otherwise, all the reverts and such will cause
confusion. If the problem still exists at the most recent merge-*
tag, then the problem is in linux-2.6 and should be bisected there.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-08-19 18:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <19075.41714.450997.244874@gargle.gargle.HOWL>
[not found] ` <1250142042.2352.26.camel@ct>
[not found] ` <200908182346.29416.kunal.gangakhedkar@gmail.com>
[not found] ` <1250629490.7534.20.camel@mj>
[not found] ` <43e72e890908181407w2d658392w1f61b7f37beb04d1@mail.gmail.com>
[not found] ` <1250630158.7534.29.camel@mj>
[not found] ` <43e72e890908181424l770b3356ie990e9cadcb39877@mail.gmail.com>
[not found] ` <1250631900.7534.44.camel@mj>
[not found] ` <20090818215748.GJ20633@mosca>
[not found] ` <20090819175809.GD5905@tuxdriver.com>
2009-08-19 18:34 ` bisecting with wireless-testing Luis R. Rodriguez
2009-08-19 18:44 ` John W. Linville
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).