Re: Basic requirements for supporting OS and machine ports.

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 18/04/2017 13:49, Florian Weimer wrote:
> On 04/18/2017 03:47 PM, Carlos O'Donell wrote:
>> (a) If your OS and machine port has build-many-glibcs.py support then all
>>      maintainers will strive to ensure that their changes do not break those
>>      OS and machine combinations supported by the script, and will work to
>>      correct any such past breakage.
> 
> I don't want to see running build-many-glibcs.py as a requirement for posting patches.  The main reason for that is that it's rather expensive (either you need to be very patient, or you need a fairly big machine).
> 
> What do you think about of out-of-tree GCC ports?  Can we support targets which are not included in any upstream GCC version, only patches on top of an upstream version which already fell out of support?
> 

My view is rather we should aim to have at least a way to proper build
a toolchain to run the basic build tests in the absence of a real or
simulated system.  I also do not think to require use build-many-glibcs.py
as requirements if you have access to a native system where you can get
meaningful check results.  As Carlos pointed out in the (c) requirement,
if a developer can not even validate a build break with current tooling
(if any), then it is up to system maintainer to keep things on track.

Also if the idea is the support out-of-tree GCC ports, we need to solve
the problem of out of date support. As we increase the minimum required
binutils and gcc version for future releases, should it prevent to do so?
Or will we have different requirements for different architectures (as we
have now for kernel support)?  I tend to view out-of-tree ports to be
cumbersome in long-term development and to generate more issue as its
usage is not actively pursuit.