Quotes of the week [LWN.net]

-rc releases suck. seriously suck. The quality of commits that went in -rc cycles was much worse than merge window commits:

All commits had the same chance of introducing a bug whether they came in a merge window or an -rc cycle. This means that -rc commits mostly end up replacing obvious bugs with less obvious ones.
While the average merge window commit changes, on average, 3x more lines than an -rc commit, the chances of a bug introduced per patch is the same, which means that bugs-per-line metric of code is much higher with -rc patches.
A merge window commit spent 50% more days, on average, in -next than a -rc commit.
The number of -rc commits that never saw any mailing list or has never been replied to on a mailing list was **way** higher than merge window commits.
For some reason, the odds of a -rc commit to be targeted for -stable is over 20%, while for merge window commits it's about 3%. I can't quite explain why that happens, but this would suggest that -rc commits end up hurting -stable pretty badly.

— Sasha Levin

Please don't edit patches by hand. It's a skill nobody should have.

— Linus Torvalds

to post comments

Quotes of the week

Posted May 3, 2018 7:21 UTC (Thu) by dgm (subscriber, #49227) [Link] (3 responses)

> don't edit patches by hand

Time for a binary patch format. That's what binary formats really are for. They say "hey, don't mess with me, you pitiful human!". And you can save bytes!

Quotes of the week

Posted May 4, 2018 7:47 UTC (Fri) by Karellen (subscriber, #67644) [Link] (1 responses)

Can't tell if sarcasm or not, but just in case it's not I'll point out that humans aren't meant to edit patches, but they are meant to be able to *read* them. Otherwise we'd still be using ed-style patches, rather than unified-style ones.

Quotes of the week

Posted May 4, 2018 11:28 UTC (Fri) by johill (subscriber, #25196) [Link]

Well, ``recountdiff'' exists for a purpose, so editing patches isn't all *that* hard. :-)

Quotes of the week

Posted May 4, 2018 17:40 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> Time for a binary patch format.

VCDIFF: https://tools.ietf.org/html/rfc3284

Quotes of the week

Posted May 4, 2018 20:00 UTC (Fri) by jezuch (subscriber, #52988) [Link] (6 responses)

> Please don't edit patches by hand. It's a skill nobody should have.

Then why did you add an ability to edit diff chunks when doing git add -p?

Quotes of the week

Posted May 4, 2018 22:50 UTC (Fri) by foom (subscriber, #14868) [Link] (5 responses)

So you can use emacs, which let's you edit diffs *not* by hand?

Quotes of the week

Posted May 5, 2018 9:20 UTC (Sat) by ceplm (subscriber, #41334) [Link]

Of course, there is also https://gitlab.com/mcepl/vim-diff_navigator

Quotes of the week

Posted May 17, 2018 22:27 UTC (Thu) by john.carter (guest, #123615) [Link] (3 responses)

I have a colleague who, in review comments, is a trifle, ahh, obsessive about trailing white space

So I enabled emacs "clobber all trailing white space" and somehow touched a patch file.

And then literally spent over a day trying to work out why the hell bitbake wouldn't apply a patch. :-(

The experience left me scarred.

Quotes of the week

Posted May 18, 2018 12:24 UTC (Fri) by madscientist (subscriber, #16861) [Link] (1 responses)

Trailing space is not always removable. I also enable it, but I ONLY enable it for programming modes: C/C++, Java, Python, Makefile, shell script, etc. I don't turn it on globally.

Quotes of the week

Posted Jan 9, 2019 13:28 UTC (Wed) by khim (subscriber, #9252) [Link]

And then someone inserts patch in the bash script using <<

Quotes of the week

Posted Jun 4, 2018 8:34 UTC (Mon) by ceplm (subscriber, #41334) [Link]

And then there are formats which have significant trailing white space (the reason I don't use Markdwon unless I have to). Sigh.