Andy Ross submitted a patch which changes the way the HUD works. Norman Vine wants the old behaviour to remain available as an option. I really shouldn't get involved in this, but ... well ... here are my views.

When a developer changes a program that is used by other people, he/she needs to consider the inconvenience that change may cause, and to minimise that inconvenience as far as is compatible with the other aims. Perhaps someone has developed other software which interfaces to FlightGear and will need to be changed to accommodate these changes.

For example, Andy says he has inverted the sense of the "compression" tag to "correct" it. If the only configuration files that matter are under our control then he should supply a patch to fix them and the correction will be complete. If users are likely to have their own files which would, after this patch, be "broken", he should consider fixing the problem in a backward-compatible manner, e.g. by deprecating the existing tag while introducing a new one.

The important point is how to judge, for each little change, whether backward compatibility is worth the effort.
Airing the proposed change and listening to objections is an OK way to do this. However, when the number of people objecting is small, the objection itself appears small unless it is backed up by reasons. Norman seems to be wanting backward compatibility in general, which may indicate that he _uses_ this flight simulator more than _plays_ with it, which is great. Unfortunately it takes a lot of effort to keep backward compatibility in every respect, and so the request is just wishful thinking unless it can be narrowed down to specific items of importance. Because Norman's skill and contributions to the project are respected, other developers want to keep the features that he values while still being able to develop the software and change things that don't seem right.

If no progress is made soon, I recommend that the "old behaviour" option be implemented, and that Andy should modify the "if" statement so that it can be selected at run time. That would seem to satisfy the current objection, subject to the compatibility of the HUD configuration files being satisfactory. Then a separate patch to delete the old functionality can be proposed immediately, and the discussion of that can continue without holding up development in the short term. When the maintenance of that old codes becomes a hindrance, that will be an argument for removing it. At least, in the short term, it will be useful to have the old version available while any "issues" with the new version are resolved.

Finally, I believe V. S. Renganathan did substantial work on the HUD for use in a research project. If anyone knows whether he is still interested in it, that might also be helpful.

Please let the resolution be swift and easy so that developers will not be put off trying to change anything.

- Julian Foad,
Secretary,
IASFGP (International Arbitration Service for Flight Gear Programmers)



_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to