Re: Submit commit 3dea642afd for 2.6.38.stable?

Re: Submit commit 3dea642afd for 2.6.38.stable?

[Luben Tuikov]

--- 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

Re: Submit commit 3dea642afd for 2.6.38.stable?

[Greg KH]

On Thu, May 19, 2011 at 10:19:54AM -0400, Alan Stern wrote:
> On Thu, 19 May 2011, James Bottomley wrote:
> 
> > 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?
> 
> I'll handle it.
> 
> Greg, can you send the commit listed above directly into the stable 
> queue, or should I email it to stable@kernel.org as a separate patch?  
> It needs to be applied to 2.6.38.x only.

Now queued up, all I needed was the git commit id above.

thanks,

greg k-h

Re: Submit commit 3dea642afd for 2.6.38.stable?

[Alan Stern]

On Thu, 19 May 2011, James Bottomley wrote:

> 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?

I'll handle it.

Greg, can you send the commit listed above directly into the stable 
queue, or should I email it to stable@kernel.org as a separate patch?  
It needs to be applied to 2.6.38.x only.

Alan Stern

Re: Submit commit 3dea642afd for 2.6.38.stable?

[Luben Tuikov]

--- 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.

    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

Re: Submit commit 3dea642afd for 2.6.38.stable?

[James Bottomley]

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.

James

Submit commit 3dea642afd for 2.6.38.stable?

[Alan Stern]

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

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?)