Greg,
We need to define the terms of reference for our discussion of proposed
changes. We need to avoid emotive arguments, like “complete red
herring”, “cascade of further failures” and “sweeping changes”. I
believe a much greater risk is not fixing issues, I believe I can
demonstrate that, given the opportunity. I also encourage all who are
interested to become involved.
Which is why I’m asking you to vote on theory driven development:
Just before Christmas, you were discussing whether to fix concurrency
problems based on theoretical analysis, or to only fix those problems
for which there is experimental evidence.
I believe the PMC will be at cross-purposes until you resolve that
issue, and strongly advise discussing and voting on it.
This is an example of a question whose answer would be obvious and
non-controversial if you had agreement, either way, on that general
issue. "When do you claim that this happens? And what currently happens
now that is unacceptable? What is the concrete, observable problem that
you’re trying to solve, that justifies introducing failures that require
further work?" is a valid, and important, set of questions if you are
only going to fix concurrency bugs for which there is experimental
evidence. It is irrelevant if you are going to fix concurrency bugs
based on theoretical analysis.
Patricia
If there are other practises you believe we should adopt, then you need
to put forward a case for voting on them, preferably after this vote
completes.
Regards,
Peter Firmstone.
On 20/01/2014 1:22 AM, Greg Trasuk wrote:
On Jan 18, 2014, at 10:45 PM, Peter Firmstone<j...@zeus.net.au> wrote:
The major problem that faces my development now however is not multi threaded
bugs, instead it is the River development community remaining undecided on
supporting or not supporting Theory based development.
You are mistaken in this statement, at least from my viewpoint. This idea of
“Theory-based development” is a complete red herring. Speaking for myself,
what concerns me is sweeping changes to code that has already been released.
Especially when those changes are followed by a cascade of further failures,
which then causes more sweeping, un-discussed changes.
I want you to involve the community (including listening to us) in discussing
the risks and benefits of making those changes, and developing a strategy to
minimize the risks. Ultimately I think we need to extend our
“review-then-commit” policy from API to the complete released codebase.
Granted, qa_refactor is an experimental branch. So eventually the community
needs to figure out how to move forward with experimental branches when they
deviate significantly from the released branches.
Cheers,
Greg.
