Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the scsi tree got conflicts in:
drivers/scsi/hosts.c
drivers/scsi/libsas/sas_task.c
drivers/scsi/scsi.c
drivers/scsi/scsi_error.c
drivers/scsi/scsi_ioctl.c
drivers/scsi/scsi_lib.c
drivers/scsi/scsi_pm.c
drivers/scsi/scsi_sysfs.c
drivers/scsi/sd.c
drivers/scsi/sr.c
drivers/scsi/st.c
between commits:
457c89965399 ("treewide: Add SPDX license identifier for missed files")
09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")
from Linus' tree and commits:
026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing licensing information")
5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")
from the scsi tree.
I fixed it up (I just used the scsi tree versions - which are GPL-2.0
instead of GPL-2.0-only) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging. You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
Hi all,
On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next merge of the scsi tree got conflicts in:
>
> drivers/scsi/hosts.c
> drivers/scsi/libsas/sas_task.c
> drivers/scsi/scsi.c
> drivers/scsi/scsi_error.c
> drivers/scsi/scsi_ioctl.c
> drivers/scsi/scsi_lib.c
> drivers/scsi/scsi_pm.c
> drivers/scsi/scsi_sysfs.c
> drivers/scsi/sd.c
> drivers/scsi/sr.c
> drivers/scsi/st.c
>
> between commits:
>
> 457c89965399 ("treewide: Add SPDX license identifier for missed files")
> 09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")
>
> from Linus' tree and commits:
>
> 026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing licensing information")
> 5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
> 5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
> 95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
> 50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")
I have now got more of these conflicts in
drivers/scsi/libsas/sas_init.c
drivers/scsi/libsas/sas_internal.h
drivers/scsi/libsas/sas_scsi_host.c
drivers/scsi/sg.c
include/scsi/libsas.h
include/scsi/sas.h
--
Cheers,
Stephen Rothwell
Hi all,
On Tue, 28 May 2019 11:43:20 +1000 Stephen Rothwell <[email protected]> wrote:
>
> On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > Today's linux-next merge of the scsi tree got conflicts in:
> >
> > drivers/scsi/hosts.c
...
> > between commits:
> >
> > 457c89965399 ("treewide: Add SPDX license identifier for missed files")
> > 09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")
> >
> > from Linus' tree and commits:
> >
> > 026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing licensing information")
> > 5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
> > 5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
> > 95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
> > 50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")
>
> I have now got more of these conflicts in
>
> drivers/scsi/libsas/sas_init.c
...
OK, so here is the complete list (so far) of files in the scsi tree
that conflict with the SPDX updates in Linus' tree:
drivers/scsi/fcoe/fcoe.c
drivers/scsi/fcoe/fcoe.h
drivers/scsi/fcoe/fcoe_ctlr.c
drivers/scsi/fcoe/fcoe_sysfs.c
drivers/scsi/fcoe/fcoe_transport.c
drivers/scsi/hosts.c
drivers/scsi/libfc/fc_disc.c
drivers/scsi/libfc/fc_elsct.c
drivers/scsi/libfc/fc_exch.c
drivers/scsi/libfc/fc_fcp.c
drivers/scsi/libfc/fc_frame.c
drivers/scsi/libfc/fc_libfc.c
drivers/scsi/libfc/fc_libfc.h
drivers/scsi/libfc/fc_lport.c
drivers/scsi/libfc/fc_npiv.c
drivers/scsi/libfc/fc_rport.c
drivers/scsi/libiscsi.c
drivers/scsi/libiscsi_tcp.c
drivers/scsi/libsas/sas_ata.c
drivers/scsi/libsas/sas_host_smp.c
drivers/scsi/libsas/sas_init.c
drivers/scsi/libsas/sas_internal.h
drivers/scsi/libsas/sas_scsi_host.c
drivers/scsi/libsas/sas_task.c
drivers/scsi/osst.c
drivers/scsi/scsi.c
drivers/scsi/scsi_error.c
drivers/scsi/scsi_ioctl.c
drivers/scsi/scsi_lib.c
drivers/scsi/scsi_logging.c
drivers/scsi/scsi_pm.c
drivers/scsi/scsi_sysctl.c
drivers/scsi/scsi_sysfs.c
drivers/scsi/scsi_trace.c
drivers/scsi/scsi_transport_fc.c
drivers/scsi/scsi_transport_iscsi.c
drivers/scsi/scsi_transport_sas.c
drivers/scsi/scsi_transport_spi.c
drivers/scsi/sd.c
drivers/scsi/sd_dif.c
drivers/scsi/sd_zbc.c
drivers/scsi/ses.c
drivers/scsi/sg.c
drivers/scsi/sr.c
drivers/scsi/st.c
include/scsi/fc/fc_encaps.h
include/scsi/fc/fc_fc2.h
include/scsi/fc/fc_fcoe.h
include/scsi/fc/fc_fcp.h
include/scsi/fc/fc_ms.h
include/scsi/iscsi_if.h
include/scsi/iscsi_proto.h
include/scsi/libfc.h
include/scsi/libfcoe.h
include/scsi/libiscsi.h
include/scsi/libiscsi_tcp.h
include/scsi/libsas.h
include/scsi/sas.h
include/scsi/sas_ata.h
include/scsi/scsi_bsg_iscsi.h
include/scsi/scsi_transport.h
include/scsi/scsi_transport_fc.h
include/scsi/scsi_transport_iscsi.h
include/scsi/scsi_transport_spi.h
At what point does it become worth while to do a back merge of v5.2-rc4
(I think the last of the SPDX changes went into there) to take care of
all these (rather than Linus having to edit each of these files himself
during the merge window)?
--
Cheers,
Stephen Rothwell
On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell <[email protected]> wrote:
>
> At what point does it become worth while to do a back merge of v5.2-rc4
> (I think the last of the SPDX changes went into there) to take care of
> all these (rather than Linus having to edit each of these files himself
> during the merge window)?
For just trivial conflicts like this that have no code, I really would
prefer no backmerges.
That said, I would tend to trust the due diligence that Thomas, Greg &
co have done, and am wondering why the scsi tree ends up having
different SPDX results in the first place..
Linus
On Thu, 2019-06-20 at 17:07 -0700, Linus Torvalds wrote:
> On Thu, Jun 20, 2019 at 4:59 PM Stephen Rothwell <[email protected]
> u> wrote:
> >
> > At what point does it become worth while to do a back merge of
> > v5.2-rc4 (I think the last of the SPDX changes went into there) to
> > take care of all these (rather than Linus having to edit each of
> > these files himself during the merge window)?
>
> For just trivial conflicts like this that have no code, I really
> would prefer no backmerges.
>
> That said, I would tend to trust the due diligence that Thomas, Greg
> & co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..
There's two problems. One is simple terminology: the
Documentation/process/licence-rules.rst say:
GPL-2.0 means GPL 2 only
GPL-2.0+ means GPL 2 or later
I believe RMS made a fuss about this and he finally agreed to
GPL-2.0-only
GPL-2.0-or-later
It's just the kernel doc hasn't been updated so Christoph did what the
doc says when making the change and Thomas did what we've apparently
agreed to with RMS, hence textual discrepencies.
The other problem is actually substantive: In the libsas code Luben
Tuikov originally specified gpl 2.0 only by dint of stating:
* This file is licensed under GPLv2.
In all the libsas files, but then muddied the water by quoting GPLv2
verbatim (which includes the or later than language). So for these
files Christoph did the conversion to v2 only SPDX tags and Thomas
converted to v2 or later tags. Based on somewhat distant recollections
of history, I believe Christoph is right on this one.
James
Linus,
> That said, I would tend to trust the due diligence that Thomas, Greg &
> co have done, and am wondering why the scsi tree ends up having
> different SPDX results in the first place..
I left Christoph's patches in my 5.3 queue after Stephen let me know
about the treewide series because, well, it came from people with SCSI
affiliation and it got reviewed.
In any case I assumed the delta was formatting or purely cosmetic. I
don't recall there being any ambiguity about choice of license or SPDX
tag when I reviewed the patches.
I have been meaning to take a closer look but have had a critical fire
eating up a bunch of my time the last couple of weeks. I'll get to it...
--
Martin K. Petersen Oracle Linux Engineering
On Thu, Jun 20, 2019 at 5:35 PM James Bottomley
<[email protected]> wrote:
>
> * This file is licensed under GPLv2.
>
> In all the libsas files, but then muddied the water by quoting GPLv2
> verbatim (which includes the or later than language).
Ok, thanks for the explanation. And yes, that would have likely
confused people who just looked at the license text.
Linus
James,
> There's two problems. One is simple terminology: the
> Documentation/process/licence-rules.rst say:
>
> GPL-2.0 means GPL 2 only
> GPL-2.0+ means GPL 2 or later
>
> I believe RMS made a fuss about this and he finally agreed to
>
> GPL-2.0-only
> GPL-2.0-or-later
Looks like there are tons of the old style SPDX tags in the kernel. Is
there going to be a treewide conversion to the new tag format?
Just wondering how much to clean up given that the files Christoph
touched only constitute a subset of the old style tags found under
drivers/scsi.
--
Martin K. Petersen Oracle Linux Engineering
On Thu, Jun 20, 2019 at 09:14:07PM -0400, Martin K. Petersen wrote:
>
> James,
>
> > There's two problems. One is simple terminology: the
> > Documentation/process/licence-rules.rst say:
> >
> > GPL-2.0 means GPL 2 only
> > GPL-2.0+ means GPL 2 or later
> >
> > I believe RMS made a fuss about this and he finally agreed to
> >
> > GPL-2.0-only
> > GPL-2.0-or-later
>
> Looks like there are tons of the old style SPDX tags in the kernel. Is
> there going to be a treewide conversion to the new tag format?
Not any time soon. Both are "valid" for us, and the tools. We are
focusing on actually tagging all files before we worry about these two
different types of tag that mean the same thing.
thanks,
greg k-h