recovery from fail

recovery from fail

[Tobin Harding]

I have made and epic fail and am asking for advice on how to proceed
to cause the least amount of upset.

I submitted a simple patch series to LKML. A reviewer made a
suggestion. I submitted v2 - without building it :(

kbuild test robot picked up that it doesn't compile. The problem is
that I now cannot get the second patch of the series to compile.

What is the correct protocol to follow?

I don't want to make any more noise than I already have but I also
don't want to ignore the reviewer by not implementing the suggested
changes.

Is it rude to reply to the original review email for further
discussion having already botched the patch?


Thanks in advance,
Tobin.

recovery from fail

[Andrey Utkin]

On Mon, Feb 13, 2017 at 12:29:04PM +1100, Tobin Harding wrote:
> I have made and epic fail and am asking for advice on how to proceed
> to cause the least amount of upset.
> 
> I submitted a simple patch series to LKML. A reviewer made a
> suggestion. I submitted v2 - without building it :(
> 
> kbuild test robot picked up that it doesn't compile. The problem is
> that I now cannot get the second patch of the series to compile.
> 
> What is the correct protocol to follow?

Fix issues and carefully submit v3 with proper list of changes since
previous submissions.

> 
> I don't want to make any more noise than I already have

Not a big deal.
Don't worry about that unless you repeatedly receive strong suggestions
to never submit anything again.

> but I also don't want to ignore the reviewer by not implementing the
> suggested changes.
> 
> Is it rude to reply to the original review email for further
> discussion having already botched the patch?

If you can fix issues on your own, just submit v3 and add all previous
reviewers to recipients list.

If you can't fix issues, proceed discussion with reviewer in whatever
way you find suitable.

recovery from fail

[valdis.kletnieks at vt.edu]

On Mon, 13 Feb 2017 23:10:39 +0000, Andrey Utkin said:
> On Mon, Feb 13, 2017 at 12:29:04PM +1100, Tobin Harding wrote:

> > I don't want to make any more noise than I already have
>
> Not a big deal.
> Don't worry about that unless you repeatedly receive strong suggestions
> to never submit anything again.

Don't worry too much, I've been around since 2.5.47 (late 2002), and out of the
thousands of people contributing to the kernel, we've have exactly *one*
person like that.

(We've had a number of people who we've suggested get a bit more competent
at C programming, but we're more than happy to hear from those people after
they've spent a few more months doing C coding...

> > but I also don't want to ignore the reviewer by not implementing the
> > suggested changes.
> >
> > Is it rude to reply to the original review email for further
> > discussion having already botched the patch?
>
> If you can fix issues on your own, just submit v3 and add all previous
> reviewers to recipients list.

Note that many subsystem maintainers will get irritated if you submit a v3
that *doesn't* fix all the issues identified so far - so stash all the comments
on the v2 patchset in a mail folder, and before you send v3, go through and
make sure you've done *something* about all the comments.

> If you can't fix issues, proceed discussion with reviewer in whatever
> way you find suitable.

And keep in mind that some reviewers are merely seeking explanations because
they don't spend a lot of time in the relevant part of the kernel. I've been
known to comment om patches with questions like "Did you consider the effect of
XYZ?" and a reply of "Yeah we thought about it, and it's not an issue because
ABC" is all that's needed...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170214/ca681d65/attachment.bin