Re: RFH: GPLv3

[DJ Delorie <dj at redhat dot com>]

Mark Mitchell <mark@codesourcery.com> writes:
> 1. The compiler proper (e.g., files used only in cc1, cc1plus, the
> driver, etc.) should all be converted to GPLv3 ASAP.

I'll note that libiberty is not used "only" in gcc.  We still need to
coordinate that change separately.

> 2. GCC 4.2.1 will be the last GPLv2 release.  The FSF will permit
> backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
> to GPLv2, as part of that release.
> 
> 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
>   What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
> emphasize the GPLv3 switch.  The GCC mainline will then be GCC 4.4.

I write this with a heavy hand, but...

I read these as "4.2.1 is the last 4.2 release".  Pulling a 4.3.3 from
that branch is, IMHO, stupid and confusing.  If 4.2.1 is the last 4.2
release, the 4.2 branch is DEAD (svn topology notwithstanding).  The
next release cannot be 4.3.3, that makes no sense.  The next release
would be 4.3.0, regardless of where it came from.  However, we've been
telling users "feature X will be in 4.3" for some time, please don't
turn us into liars.

I can see the slashdot headline now: "GCC 4.2.1 to be last 4.2
release; next major release is 4.3.3, without any of the promised 4.3
features."

Users don't care about our svn branching structure, they only care
about release numbers and functionality.

Vendors only care slightly, because they want to know the origin path
of changes, but they don't always mirror our branching structure (RH
doesn't).  But they have to explain features vs version to customers.

The SC says they don't have a choice, but they do.  They can choose to
stay with the current 4.3-as-head and let the 4.2 branch die with
4.2.1 (just hold off the 4.2.1 release until 4.3 is released ;).  That
honors the FSF's hard-headed goals, without causing confusion for the
people who use and care about gcc.

I, as a technical contributor, will not support the "4.3.3 follows
4.2.1" decision.  If RMS wants to screw the users, let RMS write the
patches.  I care about the users too much to participate in this type
of fiasco.  Perhaps others who feel as I do will agree, and the FSF
will find that there's nobody left to work on 4.3.3 any more.  Then
what?

As an aside, I consider version numbers to be, at least partially, a
technical issue, since so many packaging systems rely on them making
sense in a programatical way.  In that respect, the SC should not be
acting unilaterally, as they are not supposed to make technical
decisions.