On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law <l...@redhat.com> wrote:
> On 09/29/2015 07:19 AM, Oleg Endo wrote:
>>
>> On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:
>>
>>> We can at least change the default to LRA, so new ports get it unless
>>> they like to hurt themselves.
>>>
>>> I don't think it makes sense to keep reload around *just* for the ports
>>> that are in "maintenance mode": by the time we are down to *just* those
>>> ports, it makes more sense to relabel them as "unmaintained".
>>
>>
>> Just for my understanding ... what's the definition of "maintenance
>> mode" or "unmaintained"?
>
> I'm not sure there's any formal definition.
>
> If the port isn't getting tested, bugs aren't getting fixed, fails to build,
> etc then it's probably a good bet you could put it into the unmaintained
> bucket.
>
> If the port does get occasional fixes (primarily driven by BZs), but not
> getting updated on a regular basis (such as conversion to LRA, conversion to
> RTL prologue/epilogue, etc), may be only getting occasional testing, etc.
> Then it's probably fair to call it in maintenance mode.  A great example
> IMHO would be the m68k.

Another criteria would be available hardware for which both the PA and
alpha ports
are a good example.  When you can't buy new hardware then targets that
could formerly host GCC quickly rot to the state where only cross-compilation
is viable (and having "old" GCC is good enough).

> I would say we probably have many ports in maintenance mode right now. Not
> sure if any are in the unmaintained mode with perhaps the exception of
> interix.

I'd say that all ports not in maintainance mode should be at least secondary
archs as we can expect maintainers to be around to keep it at the quality
level we expect for secondary targets.  Now I'd like to do the opposite
conclusion and declare all non-primary/secondary targets as in
maintainance mode ... ;)
We have 49 targets (counting directories) and 7 of them compose the list of
primary and secondary triplets.

Richard.

> jeff

Reply via email to