[Rock-dev] YAML orogen config files

[Sylvain Joyeux]

>> Cost vs.benefit.
>>    Cost: it's there, it's deployed. Everyone need to change, and we'll
>> need to have backward-compatible files.
>
> I agree with you, keeping backward-compatibility will be costly, especially
> without a good plan.

You might very well be right in absolute. Maybe the pure-YAML encoding
would have been better. But this discussion is not about a new piece
of code, it's dealing with the fact that there is software that was
there for years and that is *in use*. Was this format the right
decision ? At the time, it looked like it. If other people looked at
it *at the time*, then it might have gone another way. But right now,
it's there and has been there for, what, 6-7 years ? You've been
actually using it for how long ? 3-4 years ? It's interesting that
such an absolute ugliness did not show up on your radar earlier.
Probably because, as a user, this discussion is irrelevant.

Programmer cost, then. Migrating will be much more costly than the
rewards we would get from such a change. The 30 minutes needed to
write a parser (that should be written only once per programming
language) *is* relevant. It has to be weighted against the cost of
changing everyone's config files and habits with zero benefit /
usability improvement on the user's side. So, what do we optimise for
in this case ? For 5 programming languages, we're talking about 2.5
hours of work. Let's say half a day

Assuming that changing all the config files and testing them is the
same (30 min) per user and/or project (which is an obvious
understatement, you're going to be dealing with new code) .... How
many order of magnitude more than 5 users/projects do we have ? At
least two ?

If you really want to make a dent with the accumulated "wrong stuff"
in Rock, I would be happy to provide you with things that could have a
huge cleaning impact and little to no backward compatibility costs.
They would however definitely require much more than 30 minutes of
your time.

Sylvain