1. What is the criteria for proposing deprecation for a target?

Those targets that are not considered alive using the above criteria, might be proposed to be deprecated.

People may also make their own proposals for deprecations, including relating to targets which have had results posted in the past year, and including deprecations of particular subconfigurations (e.g. using a particular target without the GNU assembler, or with a particular debug format).

2. When will a deprecated target be removed from the code?

The general idea is to deprecate in one release cycle, and to delete in a subsequent cycle. Targets would require --enable-obsolete to build them in version X.Y, then the code (and documentation, testsuite support etc.) would be removed some time after version X.Y is released if no-one comes forward to resurrect the target support. If someone does come forward, patches to resurrect the support could be accepted even in the X.Y branch if it is clear they would not affect other targets.

3. My favorite target is being deprecated, but there are a lot of users for this target. Does any part of the deprecation requirements take into account user base, or just developer base?

Neither, it is the tester base. Testing is needed to provide evidence that a target works, but in practice some developer work is needed to fix problems that show up in testing and without such work, target architectures are unlikely to remain working well between major releases.

The problem is that often users of ancient hardware will also be users of very old versions of the software; if they don't help test the latest code (the gcc trunk), then there's no way to tell whether the latest code actually works. Code that is not tested is almost always broken code.

4. But why remove something that works fine because it may rot in the future?

The interface between gcc and the back-ends changes fairly frequently, so it's necessary for a target to be maintained or it will cease to work.

It's particularly with the lack of test results that that situation becomes a problem. In the absence of test results, we will not notice when a particular target becomes broken.

Every port, working or not, imposes a certain amount of maintenance overhead. It also adds inertia, because a small change that affects every backend might discourage someone from making that change, even if it's the right thing to do.

None: TargetDeprecationFAQ (last edited 2008-01-23 22:35:50 by ManuelLopezIbanez)