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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
