|| ||Steven Bosscher <stevenb.gcc-AT-gmail.com>|
|| ||Manuel López-Ibáñez <lopezibanez-AT-gmail.com>|
|| ||Re: GCC 4.4.0 Status Report (2009-03-13)|
|| ||Fri, 13 Mar 2009 18:22:33 +0100|
|| ||Richard Guenther <rguenther-AT-suse.de>, gcc-AT-gcc.gnu.org|
|| ||Article, Thread
On Fri, Mar 13, 2009 at 5:42 PM, Manuel López-Ibáñez
> 2009/3/13 Steven Bosscher <firstname.lastname@example.org>:
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther <email@example.com> wrote:
>>> We have been asked by the SC to not branch for now but wait for
>>> the wording for the new runtime license to arrive from the FSF and
>>> that being put in place.
>> This is the saddest thing that I have seen in GCC politics so far.
> Why? The FSF is offering free legal advice *after* they put forward a
> proposal that raised doubts by some people. This is a very important
> step that will open the door for the plugins framework. So better safe
> than fast. I wish it would be faster but I can understand the FSF
As if the plugins framework matters for GCC 4.4...
There are alternatives to waiting.
For example, GCC has shipped with the old runtime license for more
than a decade. Why not return to that?
Or ship as-is and fix the license for GCC 4.5. I haven't followed the
legal discussion -- so maybe I'm being naive or I've missed it -- but
I haven't seen anyone explaining why this is not an option.
Or what about branching now and starting the gcc 4.5 development
cycle? The argument against this, that the same changes will have to
be applied to the trunk and to the release branch, is getting really
weak IMHO, because the argument does not seem to consider all those
other changes that have to be applied many more times than just twice
-- all the merges from trunk to the branches waiting to be merged for
GCC 4.5, for example.
> Moreover, a few P1 regressions have been fixed thanks to the wait.
> Also, nowadays it is very easy to work on branches. Is there anyone
> that is being held back by the release delay?
Perhaps not the individual branches. But there are interactions
between the branches, and the longer it takes to branch for GCC 4.4,
the more difficult it will be to merge all the branches in for GCC
4.5. So GCC 4.5 is *also* being delayed, not just GCC 4.4.
What is also being held back, is more than a year of improvements since GCC 4.3.
to post comments)