|
On 06/05/2014 10:25 AM, Lars Kurth
wrote:
George,
a great post. Some comments
Generally, adding subheadings will help. They are already in the
title: Risk, intuition, and freeze exceptions
Let me see what I can do.
You may also want to link to my
recent blog post
You mean the release process one? Good idea.
> "I have three goals when doing release management. In
order:"
The "in order" as a separate sentence seems somewhat odd and
interrupts the flow. Also I would emphasize
(<em></em>) bug free, awesome, on-time throughout
the document
Good idea.
> Paragraph "One of the
most time-consuming aspects ..."
This paragraph is slightly convoluted. I would try and break up
some of the sentences. Also, I would emphasize the goals as said
above, e.g. <em>more
awesome</em> and leave out the #2
OK, let me see what I can do.
> "Making decisions about
accepting or rejecting patches as release coordinator is about
making calculated risks:
making calculated risks=taking
calculated risks=calculating risk
I think you used this phrase throughout the document
> look at the benefits, look at the potential costs, look
at the probabilities, and try to make the best balance you can
out of them."
I would bulletize this list
> "risks won't pay off"
taking? "risks won't pay off"
> "You may approve a patch to go in, and it will then turn
out to have a bug in it which delays the release."
I think that is a bad example for "taking a risk not paying
off". A better example would be if taking in a patch wont have
the desired effect (e.g. another piece for feature foo was still
missing and didn't make it). In this example, the risk merely
materialized. You may want to look at this paragraph again
No, having bugs is THE risk. There are *exactly* two costs of
adding extra code: 1) making the Xen binary slightly larger, and 2)
introducing the possibility of bugs. Making the binary larger costs
hardly anything; the slightest potential benefit outweighs it. It's
introducing bugs that is the major risk to accepting any patches
during a feature freeze.
I think maybe the problem is that normally we think of something
"paying off" in a situation where you have a low probability for a
big win, and a high probability of nothing. In this case, we have a
high-probability small win, and a low-probability big loss.
Unfortunately I'm not sure I have a better English phrase for that
situation. And in any case, I want to help people to "think like a
poker player" and accept the risk of loss as just part of the
process.
> Now, research has shown that
the intuition of experts can
It would be good to link to that research
It came mostly from one of the books I mention at the bottom,
"Thinking, Fast and Slow". I'll see if I can figure out how to
refer to it properly.
> One of the key ways
"key was" soudns stylistically odd
Just a general thought: On the risk side of patches dow e make
use of coverity scan to check whether anything has become worse?
We don't scan after each patch, but I think we continue our regular
scans as we near the release, so yes, it should flag up certain
classes of bugs.
You should link to the books. As an aside, the title covers
"freeze exceptions" but only skims over the subject it
indirectly
I guess I mean, "Risk and intuition when making freeze exceptions".
In that sense, the entire article is about freeze exceptions. :-)
But maybe a brief description would be good.
I'll let you know when I have a revised version.
-George
|
