Re: Precisely why can't official FSF GNAT maintainers copy bug fixes in GNAT & its GCC-contained runtime en masse from GNAT GPL Community Edition?

[Simon Wright <simon@pushface.org>]

"Dan'l Miller" <optikos@verizon.net> writes:

> … or brand new features, for that matter?
>
> Precisely why can't official FSF GNAT maintainers copy bug fixes ••and
> brand new features•• in GNAT & its GCC-contained runtime en masse from
> GNAT GPL Community Edition?

I haven't read much of your walls of text (where do you find the time?)
but this is confused.

-----------------

(1) Someone (Randy? one of us?) finds a bug in CE & reports it to
AdaCore.

(2a) It's already fixed in their internal repo: they may tell the
reporter.

(2b) It's new. Entered into their tracking system, prioritised, fixed.

(3) It's released to their customers. Repeat from (1) until ...

(4) Feature freeze for CE release.

-----------------

(1) Start of new FSF major release: grand port of AdaCore changes to FSF
repo.

(2) Integration with parallel changes in GCC backend etc

(3) People build for their weird architectures (incl. Darwin! my
personal interest), find & report problems; sometimes they propose
patches, sometimes they get accepted (internal compiler errors and
bootstrap failures get priority)

(3a) I hove no evidence for this, but I'd expect that serious bugs get
fed back to AdaCore's own system.

(3b) Nor have I evidence that new AdaCore work trickles through into the
FSF system. I did report one bug (80888) and submitted a patch; when the
code was eventually patched, an AdaCore engineer had developed an
identical patch. Not bitter, no! so long as the product is improved.

(4) Repeat from (2) until ...

(5) Release (current is 8.1, just yesterday).

(6) Repeat from (2) for minor releases (next will be 8.2).

-----------------

The thing to remember that AdaCore don't have separate people working on
customer, CE, or FSF compilers.