--- On Wed, 5/18/11, Luben Tuikov <ltuikov@xxxxxxxxx> wrote: > From: Luben Tuikov <ltuikov@xxxxxxxxx> > Subject: Re: Submit commit 3dea642afd for 2.6.38.stable? > To: "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx>, "James Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Cc: "James Bottomley" <James.Bottomley@xxxxxxx>, "SCSI development list" <linux-scsi@xxxxxxxxxxxxxxx>, stable@xxxxxxxxxx > Date: Wednesday, May 18, 2011, 11:07 PM > --- On Wed, 5/18/11, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > wrote: > > From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > Subject: Re: Submit commit 3dea642afd for > 2.6.38.stable? > > To: "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx> > > Cc: "James Bottomley" <James.Bottomley@xxxxxxx>, > "Luben Tuikov" <ltuikov@xxxxxxxxx>, > "SCSI development list" <linux-scsi@xxxxxxxxxxxxxxx>, > stable@xxxxxxxxxx > > Date: Wednesday, May 18, 2011, 9:02 PM > > On Mon, 2011-05-16 at 16:45 -0400, > > Alan Stern wrote: > > > James: > > > > > > Your commit > 3dea642afd9187728d119fce5c82a7ed9faa9b6a > > ([SCSI] Revert > > > "[SCSI] Retrieve the Caching mode page") hasn't > been > > submitted for the > > > 2.6.38 stable tree. More people are now > getting > > hit with the > > > underlying problem; see > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=35042 > > > > OK, yes, the reversion needs sending to stable ... can > you > > do that? > > > > > Do you want to queue your commit to the stable > tree, > > or do you prefer > > > to wait until the proper repair patch: > > > > > > http://marc.info/?l=linux-scsi&m=130089710431684&w=2 > > > > > > has been merged so it can go into the stable > tree > > instead? > > > > > > Alan Stern > > > > > > P.S.: As of now, the scsi-next tree doesn't show > any > > signs of > > > reinstating Luben's original commit together with > my > > repair patch. > > > Does this mean you intend to forget about the > original > > "Retrieve the > > > Caching mode page" change, or do you intend to > merge > > them for 2.6.41?) > > > > Actually, no, I was waiting for you to send the > combined > > patch (with > > both signoffs) rather than having me reconstruct it. > > Bottomley, > > 1. How is this any different than applying Alan's patch on > top of mine? > The net effect is the same. For example, applying my patch > (reverting your > revert of my patch) and then applying Alan's would result > in what you > want, OTHER THAN what you're suggesting above would be a > single coming > FROM Alan, as opposed to one from ME and another from > Alan. > > Please explain. > > 2. Would you accept a resubmit of my patch as [1/2] from me > and [2/2] from > Alan. In fact someone can do this in their tree and you can > pull from > them. That is, why do you INSIST on this being a "singe > comming from > [Alan]". Why can it not be two commits, in which you don't > care if you > pull from someone else's tree (Alan's or Greg's or > whomever). > > 3. Or, would you accept a patch from me, that _includes_ > Alan's smaller > commit that adds a few checks to my bigger commit which > actually introduces > functionality. > > Please explain. Basically, what would've been a really simple procedure, followed by every other subsystem maintainer (other than yourself apparently), namely applying Alan's patch (http://marc.info/?l=linux-scsi&m=130089710431684&w=2) into the same tree which which already has my patch (http://marc.info/?l=linux-usb&m=129044500027668&w=2) has now turned into a broken tree, and your wanting a single commit of both, just because you reverted my patch in your own tree. Very unusual work flow. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
