On Mon, May 6, 2013 at 7:44 PM, Adam Gandelman <adamg@canonical.com> wrote:
On 05/06/2013 04:43 PM, Alan Pevec wrote:
2013/5/6 John Griffith <john.griffith@solidfire.com>:
[1] https://review.openstack.org/#**/c/28212/<https://review.openstack.org/#/c/28212/>
acked, but I'd like to see one more review
[2] https://review.openstack.org/#**/c/28207/<https://review.openstack.org/#/c/28207/>
acked, but I'd like to see one more review
[3] https://review.openstack.org/#**/c/28210/<https://review.openstack.org/#/c/28210/>
+76, -68 seems big but not that bad upon closer look and it's localized to huawei driver acked, but I'd like to see one more review
Hey Guys-
I'm probably being a stickler, and I trust John's judgment on proposing the patches as-is, but I'm a bit concerned about the following:
https://review.openstack.org/#**/c/28207/<https://review.openstack.org/#/c/28207/>
https://review.openstack.org/#**/c/28210/<https://review.openstack.org/#/c/28210/>
Both commits contain a bug fix plus some other random stuff. The former seems trivial but the second not so much. I realize we've gotten comfortable with 'git cherry-pick' but should we be more strict about ensuring backported patches contain only the minimum required to fix the bug? IMHO, I think cherry-pick'ing only works for minimal patches from master and we should be diligent about NACKing anything into stable that brings unrelated/unwated changes.
Adam
Hey Adam, Thanks for the feed-back and I agree with your point. https://review.openstack.org/#/c/28207/ is the Cherry Pick and was in fact intended to include a fix for both items. In the future we (the Cinder team and more specifically me) should probably be better about separate commits for separate issues. That being said it's basically a one line change that needed to be made so it was included, but the issue here is the commit to master and not the commit to stable. https://review.openstack.org/#/c/28210/ is another story, and I agree the addition of the fix to the formatting of the log messages should probably not be included. It started off as a single log entry with a misspelling that earned it a -1 in the review and then as we looked closer we found more and more typos and formatting issues in the log statements. It's safe as it's isolated to the logging output, however you're probably right that it should not be in this particular patch. I'm happy to remove those *extras* and resubmit. Thanks, John