lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1229958063.3345.3.camel@localhost.localdomain>
Date:	Mon, 22 Dec 2008 09:01:03 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Boaz Harrosh <bharrosh@...asas.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Jaswinder Singh <jaswinderlinux@...il.com>,
	linux-scsi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-next@...r.kernel.org, David Woodhouse <dwmw2@...radead.org>
Subject: Re: Firmware patches for SCSI

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 <James.Bottomley@...senPartnership.com> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ