Re: Submit commit 3dea642afd for 2.6.38.stable?

[Luben Tuikov <ltuikov@yahoo.com>]

--- On Wed, 5/18/11, Luben Tuikov <ltuikov@yahoo.com> wrote:
> From: Luben Tuikov <ltuikov@yahoo.com>
> Subject: Re: Submit commit 3dea642afd for 2.6.38.stable?
> To: "Alan Stern" <stern@rowland.harvard.edu>, "James Bottomley" <James.Bottomley@HansenPartnership.com>
> Cc: "James Bottomley" <James.Bottomley@suse.de>, "SCSI development list" <linux-scsi@vger.kernel.org>, stable@kernel.org
> Date: Wednesday, May 18, 2011, 11:07 PM
> --- On Wed, 5/18/11, James Bottomley
> <James.Bottomley@HansenPartnership.com>
> wrote:
> > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Subject: Re: Submit commit 3dea642afd for
> 2.6.38.stable?
> > To: "Alan Stern" <stern@rowland.harvard.edu>
> > Cc: "James Bottomley" <James.Bottomley@suse.de>,
> "Luben Tuikov" <ltuikov@yahoo.com>,
> "SCSI development list" <linux-scsi@vger.kernel.org>,
> stable@kernel.org
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html