This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.5 "integration branch"


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]