On 21/02/2017 16:14, David Edelsohn wrote:
On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque <hain...@adacore.com> wrote:
On Feb 17, 2017, at 01:10 , David Edelsohn <dje....@gmail.com> wrote:
This is not a new issue. The maintainer did not suddenly resign last
week. There have been numerous efforts to reach out to the SPE
community for over a *decade*, cajoling them to step up with
maintenance for the port. I am glad that this notice of obsolescence
has focused more attention on the long-standing problem.
Would there be a minimum level of commitment you'd like
to get to accept leaving the port in (if not this, at least
that ...) ?
[...]
There are three main areas that require attention:
1) Regular builds of the SPE configuration and regular GCC testsuite
runs that are reported to the gcc-testsuite mailing list.
2) Timely reports of any regressions.
3) An active GCC developer who is the point of contact for the SPE
port and submits patches for the port.
None of us within IBM are experts on the SPE port. Someone from the
SPE community is needed to help triage issues, debug problems and test
patches that may affect the SPE port.
With evidence of pro-active involvement from an SPE developer, the
port does not have to be deprecated. The effort needs to be more that
activity at GCC release cycle boundaries or an accelerated deprecation
process will be proposed.
I volunteer to be the point of contact for the SPE port.
Over here at CodeSourcery/Mentor Embedded, we have a strong interest in
SPE *not* being deprecated (we actively ship toolchain products with SPE
multilibs, and have customers for which these are important). We are
therefore volunteering resources (specifically, me) to maintain SPE
upstream as well.
I am in the process of developing some patches to add VLE support
upstream (and expect to be maintainer of those once they are committed)
so it would be a good fit for me to be the SPE maintainer as well.
We have been regularly running tests on the SPE multilibs (on our
internal branches) and they are in better shape than the test results
Segher found from 2015. We may have some (not yet upstreamed) patches
that improve the test results - I will be tracking these down and
upstreaming them ASAP. I will be expanding our regular build and test
runs to cover trunk as well, and will send test results to gcc-testsuite
and report regressions.
If there is no objection, I will submit patches tomorrow to un-obsolete
SPE and add myself to the appropriate section of the MAINTAINERS file.
The other changes will come once stage 1 opens.
Thanks,
Andrew
