dev process - reduce mistakes

dev process - reduce mistakes

[Tobin C. Harding]

Hi,

I'm after some advice from those more experienced with [kernel]
development please.

What systems do you have in place to help catch mistakes?  In other
words; what processes do you use when coding and submitting patches to
help eliminate simple mistakes?  So far my best method is getting a
patch [set] ready then waiting until the next day before reviewing the
set and submitting.  I am facing an issue where by when doing (less than
super interesting) large patch sets (like docs fixes) that by the time I
get to the final review my eyes glaze over and I'm still missing
mistakes.

My future maintainers will thank you ;)


thanks,
Tobin.

dev process - reduce mistakes

[valdis.kletnieks at vt.edu]

On Wed, 19 Sep 2018 09:35:36 +1000, "Tobin C. Harding" said:
> Hi,
>
> I'm after some advice from those more experienced with [kernel]
> development please.
>
> What systems do you have in place to help catch mistakes?  In other
> words; what processes do you use when coding and submitting patches to
> help eliminate simple mistakes?

Same way you verify it for any other large programming project.

'make clean && make && make install && shutdown -r now'

1) Verify no compile errors.

2) Verify no unexplained compile warnings. gcc *does* screw up and whine about
things incorrectly on occasion because it doesn't know everything - "variable
may be used uninitialized" is a famous one, usually emitted because there's
program logic it can't see. For instance, code like:

    int oddball;
    for (i=0;i<foo;i++) {
         if (wombat > 5) oddball = 7;
         if (frobozz) quux = oddball;
    }

and there's a reason known to programmer but not compiler
that guarantees that wombat > 5 will always happen at least once
before frobozz becomes true.

But in general, unless you can *prove* the compiler is false-positive on
a warning, fix the warning. ;)

2a) (optional) Install 'sparse' and do a 'make C=2' and see if that complains about
anything that gcc didn't...

3) Test that it actually boots and does whatever your patch is supposed to do.

See? And here you thought it was difficult :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180918/e7cc0f11/attachment.sig>

dev process - reduce mistakes

[Cindy-Sue Causey]

On 9/18/18, Tobin C. Harding <me@tobin.cc> wrote:
> Hi,
>
> I'm after some advice from those more experienced with [kernel]
> development please.
>
> What systems do you have in place to help catch mistakes?  In other
> words; what processes do you use when coding and submitting patches to
> help eliminate simple mistakes?  So far my best method is getting a
> patch [set] ready then waiting until the next day before reviewing the
> set and submitting.  I am facing an issue where by when doing (less than
> super interesting) large patch sets (like docs fixes) that by the time I
> get to the final review my eyes glaze over and I'm still missing
> mistakes.
>
> My future maintainers will thank you ;)


For the docs part of what you're doing, *I* read what I write out loud
and deliberately very slowly so that I actually see each word. I
*empathize* with you. I experience something similar regarding my
often long winded emails. I'll proofread literally 10 or 15 times then
see that one last mistake...

That I MISSED... as the email is disappearing out of sight because it
has just been sent to a listserv. :D

Reading out loud **slower** than I normally would helps me see AND
hear mistakes. If I read at a normal speed, even if I do so out loud,
it's some kind of a Human nature thing that I'll keep reading my
mistakes wrongly by mentally "glossing over" those mistakes instead of
seeing them for the oopsies they are. Instead of catching those
mistakes and fixing them, I just keep saying them WRONG out loud over
and over (AND over) if I do so at a normal conversational speaking
speed. :))

Have fun!

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* 'Twas brillig and the slithy tove, yada-yada.... *

dev process - reduce mistakes

[Tobin C. Harding]

On Tue, Sep 18, 2018 at 08:01:22PM -0400, valdis.kletnieks at vt.edu wrote:
> On Wed, 19 Sep 2018 09:35:36 +1000, "Tobin C. Harding" said:
> > Hi,
> >
> > I'm after some advice from those more experienced with [kernel]
> > development please.
> >
> > What systems do you have in place to help catch mistakes?  In other
> > words; what processes do you use when coding and submitting patches to
> > help eliminate simple mistakes?
> 
> Same way you verify it for any other large programming project.
> 
> 'make clean && make && make install && shutdown -r now'
> 
> 1) Verify no compile errors.
> 
> 2) Verify no unexplained compile warnings. gcc *does* screw up and whine about
> things incorrectly on occasion because it doesn't know everything - "variable
> may be used uninitialized" is a famous one, usually emitted because there's
> program logic it can't see. For instance, code like:
> 
>     int oddball;
>     for (i=0;i<foo;i++) {
>          if (wombat > 5) oddball = 7;
>          if (frobozz) quux = oddball;
>     }
> 
> and there's a reason known to programmer but not compiler
> that guarantees that wombat > 5 will always happen at least once
> before frobozz becomes true.
> 
> But in general, unless you can *prove* the compiler is false-positive on
> a warning, fix the warning. ;)
> 
> 2a) (optional) Install 'sparse' and do a 'make C=2' and see if that complains about
> anything that gcc didn't...
> 
> 3) Test that it actually boots and does whatever your patch is supposed to do.
> 
> See? And here you thought it was difficult :)



Thanks for your response Valdis (especially the wombat reference).  I'm
talking though about more brain dead mistakes like:

- Muddling up changes between patches when rebasing
- Missing an instance of a series of the same changes (usually because
  you did 100 of them and one slipped past when viewing the diff)


Things that don't make the compiler or static analysis complain.  I made
an improvement on my method today and that was to review patch sets
[almost] ready for submission first thing in the day so your eyes/brain
is fresh.

These sort of 'soft' ideas I'm after please.  I'm sure the old fellas
have a bunch of them that they do unconsciously but any that any one can
think of would be great to hear.

thanks,
Tobin.

dev process - reduce mistakes

[Tobin C. Harding]

On Tue, Sep 18, 2018 at 10:01:19PM -0400, Cindy-Sue Causey wrote:
> On 9/18/18, Tobin C. Harding <me@tobin.cc> wrote:
> > Hi,
> >
> > I'm after some advice from those more experienced with [kernel]
> > development please.
> >
> > What systems do you have in place to help catch mistakes?  In other
> > words; what processes do you use when coding and submitting patches to
> > help eliminate simple mistakes?  So far my best method is getting a
> > patch [set] ready then waiting until the next day before reviewing the
> > set and submitting.  I am facing an issue where by when doing (less than
> > super interesting) large patch sets (like docs fixes) that by the time I
> > get to the final review my eyes glaze over and I'm still missing
> > mistakes.
> >
> > My future maintainers will thank you ;)
> 
> 
> For the docs part of what you're doing, *I* read what I write out loud
> and deliberately very slowly so that I actually see each word. I
> *empathize* with you. I experience something similar regarding my
> often long winded emails. I'll proofread literally 10 or 15 times then
> see that one last mistake...
> 
> That I MISSED... as the email is disappearing out of sight because it
> has just been sent to a listserv. :D
> 
> Reading out loud **slower** than I normally would helps me see AND
> hear mistakes. If I read at a normal speed, even if I do so out loud,
> it's some kind of a Human nature thing that I'll keep reading my
> mistakes wrongly by mentally "glossing over" those mistakes instead of
> seeing them for the oopsies they are. Instead of catching those
> mistakes and fixing them, I just keep saying them WRONG out loud over
> and over (AND over) if I do so at a normal conversational speaking
> speed. :))
> 
> Have fun!
> 
> Cindy :)

Awesome, thanks Cindy.  Just the sort of tip I was after.

thanks,
Tobin.