From: Bjørn Mork <redacted>
Date: Sat, 23 Jun 2012 11:26:54 +0200
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?
I'm extremely reluctant to have a dependency on another tree.
The USB tree, on the other hand, could pull the net-next tree
in so you can continue your dependent work there.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller [off-list ref] writes:
From: Bjørn Mork <bjorn@mork.no>
Date: Sat, 23 Jun 2012 11:26:54 +0200
quoted
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?
I'm extremely reluctant to have a dependency on another tree.
fair enough
The USB tree, on the other hand, could pull the net-next tree
in so you can continue your dependent work there.
OK, that will be up to Greg then.
But failing that, would it be OK to let the 3.6 version of the fix wait
for -rc2? It's not a crash or any other kind of data loss bug, just a
usability regression with a workaround.
Bjørn
David Miller [off-list ref] writes:
From: Bjørn Mork <bjorn@mork.no>
Date: Sat, 23 Jun 2012 11:26:54 +0200
quoted
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?
I'm extremely reluctant to have a dependency on another tree.
The USB tree, on the other hand, could pull the net-next tree
in so you can continue your dependent work there.
Hello Greg,
I know I said I would be more careful about cross-tree dependencies, but
here I am again...
The context is: How should I proceed with interface number based probing
for usbnet drivers, in particular qmi_wwan which already has a few
patches in net-next?
I see two possible remaining options:
1) you pull the net-next changes into usb-next so that I can do the
work against usb-next now, or
2) I wait for 3.6-rc1 and do the work against the net tree after
3.6-rc1 is merged there
I have decided to go for option #2 unless either of you have other
preferences, as I believe that is going to cause the least work and
merge trouble for you both.
The changes are mostly device IDs, but I am also going to rip out all
the whitelist probing logic becoming redundant. This is a single driver
and pretty obvious low risk though, so I believe it is appropriate for
an -rc2.
But please let me know if I'm on the wrong track here.
Bjørn