> Ideally, you should create a general copyright assignment to GCC -- a > "futures" assignment of all patches for GCC. you can select which > patches to contribute. > > If you insist on limiting it, you can specify files. But that always > runs into the potential problem of files that were omitted from the > list (such as a configuration file) or changes to additional files > requested by reviewers. Also, GCC generally likes developers to > continue to maintain contributions. > > I don't know the relationship / friendliness between AdaLabs and > AdaCore. Another possibility is that you make a private arrangement
Let me answer this part: Adacore has decided to baseline all its support for VMS which was not longer economically viable for us as an active platform and required too much special cases to be kept as is, getting in the way of further enhancements and clean ups for other platforms. That's why we completely removed all support for Ada in our current toolset as well as in the FSF GCC a few years ago, to stop having the burden to maintain this complex part of the technology. We welcomed AdaLabs initiative and encouraged it, even passing several commercial leads, since we want to have an as lively Ada ecosystem as possible. > to assign the copyright to AdaCore and they contribute the actual > patches to the GCC Project. As per above, we are not looking forward putting VMS Ada support back in GCC, even less having to maintain it directly on indirectly, but this is all theoretical anyway, since all this work is based on a relatively old version of GCC now, and we're no longer talking about "patching some files" at this stage, but about potentially restoring dozens of files, and thousands of lines of new patches to restore code that was removed throughout the general Ada files, which I don't see us accepting at this stage: this would create a too large maintenance burden on general Ada files that would impact the maintenance of all existing live Ada ports. Arno
