GCC 3.5 "integration branch"

GCC 3.5 "integration branch"

[David Edelsohn]

We understand that some developers found it frustrating that it took a
long time for a GCC 3.4 release branch to be created and the trunk to be
opened for new features.  During the GCC 3.3 release cycle, the GCC
Steering Committee and Release Manager authorized a GCC 3.4 Basic
Improvements Branch with mixed results.  The GCC SC and RM consciously
decided not to follow that model for the GCC 3.4 release cycle.

We feel that the unauthorized creation of an "integration branch" for 3.5,
while well-intentioned, was counterproductive and usurped the
responsibilities of the GCC SC and RM to manage GCC development.  This was
especially unfortunate when objections to the "integration branch"
proposal, solicited by a developer, were ignored.  While the GNU GCC
Project encourages development branches, primary GNU GCC development
branches are the responsibility of the GCC SC and RM.

The GCC Steering Committee <http://gcc.gnu.org/steering.html>

Re: GCC 3.5 "integration branch"

[Geoff Keating]

David Edelsohn <edelsohn@gnu.org> writes:

> We feel that the unauthorized creation of an "integration branch" for 3.5,

I object in the strongest possible terms to this statement.  The
creation of the branch was not unauthorized.  My authority was
<http://gcc.gnu.org/cvswrite.html>, which clearly states:

> Free for all
> 
> The following changes can be made by everyone with CVS write access:
> ...
> Creating and using a branch for development, including outside the
> parts of the compiler one maintains, provided that changes on the
> branch have copyright assignments on file. Merging such developments
> back to the mainline still needs approval in the usual way.

This paragraph was written by Joseph Meyers following a statement by
Mark Mitchell, and was then approved by Mark Mitchell.

I demand that the SC promptly correct the false and personally hurtful
statement it made.

> This was especially unfortunate when objections to the "integration
> branch" proposal, solicited by a developer, were ignored.

I would like to make it clear that no objections were ignored.  Each
comment was considered, but there was no proposed alternative course
of action that fixed the problems I described.

Indeed, I saw one alternative course of action proposed, by Mark
Mitchell, and it at best partially addressed only one of the three
problems.

> While the GNU GCC Project encourages development branches, primary GNU
> GCC development branches are the responsibility of the GCC SC and RM.

I would also like to make it clear that I did not intend this branch
to be the responsibity of the GCC SC, or of the RM; I believe I made
it quite clear that it would be my responsibility.  Nor did I intend
that this would be a 'primary GNU GCC development branch' by the
dictionary definition.  I designed the rules for the branch to ensure
that this branch was clearly secondary to the trunk.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.5 "integration branch"

[Joe Buck]

David Edelsohn <edelsohn@gnu.org> writes:
> > We feel that the unauthorized creation of an "integration branch" for 3.5,

On Tue, Jan 20, 2004 at 04:00:42PM -0800, Geoff Keating wrote:
> I object in the strongest possible terms to this statement.  The
> creation of the branch was not unauthorized.  My authority was
> <http://gcc.gnu.org/cvswrite.html>, which clearly states:
> 
> > Free for all
> > 
> > The following changes can be made by everyone with CVS write access:
> > ...
> > Creating and using a branch for development, including outside the
> > parts of the compiler one maintains, provided that changes on the
> > branch have copyright assignments on file. Merging such developments
> > back to the mainline still needs approval in the usual way.

Geoff, you meant well.  But there are some things that we have to watch
for if we don't want to severely undercut the effectiveness of the RM.

You did not create and use a branch for development.  Rather, you
created an *integration* branch, and for all practical purposes (despite
disclaimers) said that the purpose of that branch was to start 3.5.  This
gave the appearance that you were trying to go around Mark's attempt to
use the only leverage that he had to get people to focus on fixing
regressions, the same one that Linus Torvalds commonly uses: get people to
focus on getting quality up by delaying the opening of the x.y+1 tree.
The point quickly became moot because the criterion for branching 3.4 was
met a few days later, but nevertheless this felt like a bad precedent to
us.

> > This was especially unfortunate when objections to the "integration
> > branch" proposal, solicited by a developer, were ignored.
> 
> I would like to make it clear that no objections were ignored.  Each
> comment was considered, but there was no proposed alternative course
> of action that fixed the problems I described.

In http://gcc.gnu.org/ml/gcc/2004-01/msg00578.html you wrote:

> Any objections to this proposal? If not, I'll create the branch in the
> next few days.

You said you would do it if there were no objections, not that consider
whether or not people's objections were worthy.  And notice that you are
suddenly raising the bar here.  First you asked for unanimous consent, and
then you started saying that you would do it unless all the problems you
identified were solved by some other means.

The problems you described were justifications for your desire to start
3.5 right away, and Mark wanted people to fix 3.4 a bit more first (and
only a very little bit more, judging by when 3.4 was branched).  The RM's
only real power is to say no, and if you stop him from saying no, you
decrease his effectiveness.

> I would also like to make it clear that I did not intend this branch
> to be the responsibity of the GCC SC, or of the RM; I believe I made
> it quite clear that it would be my responsibility.  Nor did I intend
> that this would be a 'primary GNU GCC development branch' by the
> dictionary definition.  I designed the rules for the branch to ensure
> that this branch was clearly secondary to the trunk.

It really didn't seem that way to me.  It seemed like, despite your
disclaimers, you were starting 3.5, that is, that the rules for getting
something into 3.5-integration-branch would be the same as if 3.5 stage 1
had started: everything could go into your branch, and then it would have
a free ride with no extra approval onto the trunk when 3.4 branched.
Modulo the extra CVS clutter, there was no operational difference than if
you just declared 3.5 stage 1 open the day you created the branch.
You were basically declaring yourself owner of 3.5 until Mark agreed to
let 3.5 begin.  You even used the term, 3.5-integration-branch.

As Phil Edwards pointed out, you created a non-trunk trunk.

I'm fine with changing the rules for next time.  Mark has to execute based
on whatever rules we set down, though, so he needs to be signed up, not
disempowered and bypassed.

Re: GCC 3.5 "integration branch"

[Paul Jarc]

Geoff Keating <geoffk@geoffk.org> wrote:
> I designed the rules for the branch to ensure that this branch was
> clearly secondary to the trunk.

ISTM that your rules for the integration branch made it inherently
pointless.  One of the criteria for anything to be committed to it was
that the patch must be approved for mainline.  If that meant for the
then-current mainline, i.e. 3.4, then obviously no 3.5 work could go
on there.  OTOH, if that meant "approved for 3.5", then nothing could
be committed either, since 3.5 stage 1 had not yet begun, and thus
nothing was going to be approved.


paul

Re: GCC 3.5 "integration branch"

[Momchil Velikov]

>>>>> "David" == David Edelsohn <edelsohn@gnu.org> writes:

David> We feel that the unauthorized creation of an "integration
David> branch" for 3.5, while well-intentioned, was counterproductive
David> and usurped the responsibilities of the GCC SC and RM to manage
David> GCC development.  This was especially unfortunate when
David> objections to the "integration branch" proposal, solicited by a
David> developer, were ignored.  While the GNU GCC Project encourages
David> development branches, primary GNU GCC development branches are
David> the responsibility of the GCC SC and RM.

  This is absurd.

  How is it counterproductive?  How exactly the development of GCC is
hurt (or is expected to be hurt) by such a branch?

  As I understand it, there's a lack of consensus whether GCC should
go the tree-ssa way or the non-tree-ssa way.

  What could be better than exploring both ways, by creating a line of
development specifically for competing with the current mainline?  In
fact, it's the SC, who should have created this branch.

  Also, the very notion of "authorization to create branch" is
disturbing.  Because this directly means "authorization to work on
GCC".

  If the need for such an authorization is dictated by administrative
and/or technical reasons, the SC will better spent its time thinking
how to replace the SCM, which is the counterproductive factor
actually, as demonstrated by this very thread.

David> and usurped the responsibilities of the GCC SC and RM to manage
David> GCC development.

  Sounds familiar, eh? Like EGCS "usurped" the responsibilities of FSF
maintainers.  Which, at the end, was good for GCC and GNU, no?

~velco

Re: GCC 3.5 "integration branch"

[Paul Jarc]

Momchil Velikov <velco@fadata.bg> wrote:
>   How is it counterproductive?  How exactly the development of GCC is
> hurt (or is expected to be hurt) by such a branch?

Given the opportunity, many people will work on new functionality (for
3.5) rather than fixing bugs (for 3.4).  To encourage people to fix
bugs instead, the release manager decided not to accept new
functionality patches for 3.5 yet.

>   What could be better than exploring both ways, by creating a line of
> development specifically for competing with the current mainline?

That wasn't the purpose of the integration branch.  Go back and read
the announcement when the branch was created.

>   Also, the very notion of "authorization to create branch" is
> disturbing.  Because this directly means "authorization to work on
> GCC".

No.  People who want to work on new features can always do that on
their own machines.  The FSF (through the steering committee and the
release manager) only decides what kind of work will be accepted *on
its CVS servers* at any particular time, so as to encourage different
kinds of work at different times.  People who work on the parts of GCC
that the release manager wants to have work done on (at the time, that
was fixing bugs for 3.4) are aided by the FSF in the form of a CVS
server where they can coordinate their work.  If there were lots of
people fixing bugs anyway, then a branch for 3.4 or 3.5 probably would
have been created earlier.  But since there weren't such people,
encouragement was needed in order to ensure 3.4's quality.  (Though
some would argue that 3.4 was already good enough.)

>   If the need for such an authorization is dictated by administrative
> and/or technical reasons, the SC will better spent its time thinking
> how to replace the SCM, which is the counterproductive factor
> actually, as demonstrated by this very thread.

That hasn't been demonstrated.  What has been demonstrated is that
people disagree about what is the most productive course of action.


paul