Hi,
Philip Oakley wrote:
> That assumes that [git pull] doing something is better than doing nothing,
> which is appropriate when the costs on either side are roughly
> similar.
I think the conversation's going around in circles.
Potential next steps:
a. Documentation or test patch illustrating desired behavior
b. More traditional formal design doc explaining desired behavior and
the thinking behind it ("problem", "overview of solution",
"alternatives rejected", "complications", "example", "open
questions").
c. Implementation patch
d. Someone takes an existing patch and figures out the next step
toward getting it ready for application.
My preference is for (a), I guess.
The point being that something more concrete (code or a design doc)
makes it easier to avoid talking past each other. And having
something concrete to edit makes the stakes clearer so people can make
it incrementally better without being distracted by unimportant parts.
Thanks and hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
