To semi-rolling or not to semi-rolling, that is the question...

[Kevin Kofler]

Doug Ledford wrote:
> But let's be clear.  That's a *policy* decision.  One of the things that
> got very confusing in the previous thread(s) was the intermixing of
> policy decisions and technical issues.  For instance, Kevin's response
> to my proposal was all about technical issues he saw.  Technical issues
> are almost always solvable if you have a specific policy you are trying
> to implement.  So one thing I think people should keep in mind is that
> policy decisions should always lead to technical decisions, *not* the
> other way around.  We should decide what we want ourselves to be and
> what our policies are, and then that should guide our infrastructure,
> our tools, our work flows, and our processes.  We should never allow
> things to flow in the reverse direction.  We should never allow a
> current tooling limitation to set our policy, modulo that our policy
> should acknowledge and accommodate for the time necessary for tooling
> changes to take place or for the limitations of our resources.

I heavily disagree with that assertion. We need to always keep the technical 
and practical limitations in mind when deciding on a policy. It doesn't make 
sense to enact a policy which cannot be realized due to technical 
limitations, or whose realization causes unsolvable problems. The technical 
details are essential. Only a policy with a good technical implementation 
can be a good policy.

I can set a policy that we should colonize Mars by 2011, people may love 
that policy, but then they'll be really angry when either I have to tell 
them that we have no way to actually do that, or I send people to Mars in 
some crappy improvised equipment and they all die on the way. Heck, even if 
the goal is technically "met" and some people arrive there alive, the policy 
can still be a failure, e.g. if everyone dies within a week of arriving 
because the oxygen supplies run out.

We need to make sure that whatever we decide is actually feasible, and 
consider the technical limitations of the proposed implementation as an 
integral part of the proposal. Explaining them away as "technical" won't 
make them any less real.

        Kevin Kofler