Re: Basic requirements for supporting OS and machine ports.

[Carlos O'Donell <carlos at redhat dot com>]

On 04/18/2017 01:33 PM, Adhemerval Zanella wrote:
> 
> 
> 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.

I don't want to require build-many-glibcs.py be used as the method
for testing your patches, but I do want to require that for a machine
and OS to be supported, that you must have build-many-glibcs.py working,
and that way we can hold maintainers responsible for fixing issues it
detects.

I write "strive to ensure their changes do not break those..." which
can include just doing a native build, and not using build-many-glibcs.py.

> 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.

An out-of-tree GCC port gets (c)-level support.

You can't have a working build-many-glibcs.py without a checked in
working version of GCC from upstream.

I will not support extending build-many-glibcs.py to apply patches
to the checked out trees. Or to put it another way: We will not be
duplicating crosstool-NG in glibc :-)

-- 
Cheers,
Carlos.