Hello all,
These SCSI's firmware patches are floating in linux-next from long time :
1. qla1280: use request_firmware
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=7c84df1aec1bbb4e43ac9e2ba65b137042279a8d
2. advansys: use request_firmware
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=baca2b168d3b7340eac87414c046f7d49de4bf71
3. qlogicpti: use request_firmware
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=2c68b5b6db13786a425accc8576217b120f885f2
Should I need to resend these patches to merge main-stream.
Thank you,
Jaswinder Singh.
On Sat, 2008-12-20 at 01:23 +0530, Jaswinder Singh wrote:
> Hello all,
>
> These SCSI's firmware patches are floating in linux-next from long time :
>
> 1. qla1280: use request_firmware
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=7c84df1aec1bbb4e43ac9e2ba65b137042279a8d
> 2. advansys: use request_firmware
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=baca2b168d3b7340eac87414c046f7d49de4bf71
> 3. qlogicpti: use request_firmware
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=2c68b5b6db13786a425accc8576217b120f885f2
>
> Should I need to resend these patches to merge main-stream.
Um ... depends how they got into linux-next. The head commit just says
Merge commit 'firmware/master'
Which isn't very descriptive of where it came from. It looks like
either a tree that linux-next shouldn't pull (or one the owner forgot to
push to linus).
James
Hello James,
On Sat, Dec 20, 2008 at 1:59 AM, James Bottomley
<[email protected]> wrote:
>
> Um ... depends how they got into linux-next. The head commit just says
>
They got into linux-next via David Woodhouse. :
http://git.infradead.org/users/dwmw2/firmware-2.6.git
> Merge commit 'firmware/master'
>
> Which isn't very descriptive of where it came from. It looks like
> either a tree that linux-next shouldn't pull (or one the owner forgot to
> push to linus).
>
Earlier due to Firmware issues firmware patches are going directly
though David Woodhouse.
Now firmware issues are solved so David wants that the _driver_
patches should be sent directly to the appropriate maintainers / mailing lists.
So I am curious that should I resend these patches based on which git tree.
Thank you,
Jaswinder Singh.
On Sat, 2008-12-20 at 02:11 +0530, Jaswinder Singh wrote:
> Hello James,
>
> On Sat, Dec 20, 2008 at 1:59 AM, James Bottomley
> <[email protected]> wrote:
> >
> > Um ... depends how they got into linux-next. The head commit just says
> >
>
> They got into linux-next via David Woodhouse. :
> http://git.infradead.org/users/dwmw2/firmware-2.6.git
>
> > Merge commit 'firmware/master'
> >
> > Which isn't very descriptive of where it came from. It looks like
> > either a tree that linux-next shouldn't pull (or one the owner forgot to
> > push to linus).
> >
>
> Earlier due to Firmware issues firmware patches are going directly
> though David Woodhouse.
>
> Now firmware issues are solved so David wants that the _driver_
> patches should be sent directly to the appropriate maintainers / mailing lists.
OK, then whatever tree contains them needs to eject them or be dropped
from linux-next.
> So I am curious that should I resend these patches based on which git tree.
Yes please. For me it would be against scsi-misc ... for the other
drivers it would be their development tree. The simplest thing to do is
probably to rebase them all on top of linux-next (which contains all of
our trees) and then send them to the individual subsystem maintainer
lists.
James
Hi James,
On Fri, 19 Dec 2008 15:53:51 -0500 James Bottomley <[email protected]> wrote:
>
> OK, then whatever tree contains them needs to eject them or be dropped
> from linux-next.
That is a problem for me and David. Do not let it concern you ... :-)
> > So I am curious that should I resend these patches based on which git tree.
>
> Yes please. For me it would be against scsi-misc ... for the other
> drivers it would be their development tree. The simplest thing to do is
> probably to rebase them all on top of linux-next (which contains all of
> our trees) and then send them to the individual subsystem maintainer
> lists.
Please don't do that, please base each one on either Linus' tree or the
appropriate maintainer's subsystem tree as linux-next is a moving
target (for instance, if you had based the scsi ones on next-20081219,
then the scsi tree was not included ...). Basing on Linus' tree should
work in most cases as there are not to many conflicts caused by these
patches (the tg3 one is the worst so basing that off the net tree is
probably worth while).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Stephen Rothwell wrote:
> Hi James,
>
> On Fri, 19 Dec 2008 15:53:51 -0500 James Bottomley <[email protected]> wrote:
>> OK, then whatever tree contains them needs to eject them or be dropped
>> from linux-next.
>
> That is a problem for me and David. Do not let it concern you ... :-)
>
>>> So I am curious that should I resend these patches based on which git tree.
>> Yes please. For me it would be against scsi-misc ... for the other
>> drivers it would be their development tree. The simplest thing to do is
>> probably to rebase them all on top of linux-next (which contains all of
>> our trees) and then send them to the individual subsystem maintainer
>> lists.
>
> Please don't do that, please base each one on either Linus' tree or the
> appropriate maintainer's subsystem tree as linux-next is a moving
> target (for instance, if you had based the scsi ones on next-20081219,
> then the scsi tree was not included ...). Basing on Linus' tree should
> work in most cases as there are not to many conflicts caused by these
> patches (the tg3 one is the worst so basing that off the net tree is
> probably worth while).
>
I think what James meant is to rebase over linux-next when cutting the
patches in order to send them to the different maintainers over email.
In that case linux-next is perfect because you are sure none of the
patches will conflict with any maintainer and you do that all in one
place. Since you are not merging then linux-next volatility does not
matter.
My $0.017
Boaz
On Mon, 2008-12-22 at 09:48 +0200, Boaz Harrosh wrote:
> Stephen Rothwell wrote:
> > Hi James,
> >
> > On Fri, 19 Dec 2008 15:53:51 -0500 James Bottomley <[email protected]> wrote:
> >> OK, then whatever tree contains them needs to eject them or be dropped
> >> from linux-next.
> >
> > That is a problem for me and David. Do not let it concern you ... :-)
> >
> >>> So I am curious that should I resend these patches based on which git tree.
> >> Yes please. For me it would be against scsi-misc ... for the other
> >> drivers it would be their development tree. The simplest thing to do is
> >> probably to rebase them all on top of linux-next (which contains all of
> >> our trees) and then send them to the individual subsystem maintainer
> >> lists.
> >
> > Please don't do that, please base each one on either Linus' tree or the
> > appropriate maintainer's subsystem tree as linux-next is a moving
> > target (for instance, if you had based the scsi ones on next-20081219,
> > then the scsi tree was not included ...). Basing on Linus' tree should
> > work in most cases as there are not to many conflicts caused by these
> > patches (the tg3 one is the worst so basing that off the net tree is
> > probably worth while).
> >
>
> I think what James meant is to rebase over linux-next when cutting the
> patches in order to send them to the different maintainers over email.
> In that case linux-next is perfect because you are sure none of the
> patches will conflict with any maintainer and you do that all in one
> place. Since you are not merging then linux-next volatility does not
> matter.
Yes, that's precisely what I meant, thanks!
The point is that it's hard to work out where all the maintainer trees
are, and git makes rebasing an easy exercise, so you just prepare your
patch set against one version of linux-next ... you can rebase it to
future versions as much as you like until you're ready with
git-send-email to send off the patch sets. Linux-next is only useless
as a base for an upstream git tree; it makes a good work ground for a
volatile one that's essentially only holding patches for onward
transmission (as patches not as a git tree).
I suppose the caveat is that you have to be intimately familiar with how
git rebase works, so this course of action isn't for the faint of heart.
James
On Mon, 22 Dec 2008 09:01:03 -0600 James Bottomley <[email protected]> wrote:
>
> On Mon, 2008-12-22 at 09:48 +0200, Boaz Harrosh wrote:
> >
> > I think what James meant is to rebase over linux-next when cutting the
> > patches in order to send them to the different maintainers over email.
> > In that case linux-next is perfect because you are sure none of the
> > patches will conflict with any maintainer and you do that all in one
> > place. Since you are not merging then linux-next volatility does not
> > matter.
Unless there are conflict resolutions in the linux-next tree (and there
are a few) that involve the files in the generated patch. In that case
the patch may not apply cleanly to any of the individual trees.
> The point is that it's hard to work out where all the maintainer trees
Hopefully you can glean that information from the MAINTAINERS file or the
Trees file in any linux-next tree (available via git-web if not from the
tree itself).
Just pointing out the possible problems ...
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/