* GCC 3.5 "integration branch" @ 2004-01-20 18:24 David Edelsohn 2004-01-21 0:00 ` Geoff Keating 2004-01-21 10:22 ` Momchil Velikov 0 siblings, 2 replies; 6+ messages in thread From: David Edelsohn @ 2004-01-20 18:24 UTC (permalink / raw) To: gcc 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.5 "integration branch" 2004-01-20 18:24 GCC 3.5 "integration branch" David Edelsohn @ 2004-01-21 0:00 ` Geoff Keating 2004-01-21 1:27 ` Joe Buck 2004-01-21 7:15 ` Paul Jarc 2004-01-21 10:22 ` Momchil Velikov 1 sibling, 2 replies; 6+ messages in thread From: Geoff Keating @ 2004-01-21 0:00 UTC (permalink / raw) To: gcc 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.5 "integration branch" 2004-01-21 0:00 ` Geoff Keating @ 2004-01-21 1:27 ` Joe Buck 2004-01-21 7:15 ` Paul Jarc 1 sibling, 0 replies; 6+ messages in thread From: Joe Buck @ 2004-01-21 1:27 UTC (permalink / raw) To: Geoff Keating; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.5 "integration branch" 2004-01-21 0:00 ` Geoff Keating 2004-01-21 1:27 ` Joe Buck @ 2004-01-21 7:15 ` Paul Jarc 1 sibling, 0 replies; 6+ messages in thread From: Paul Jarc @ 2004-01-21 7:15 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.5 "integration branch" 2004-01-20 18:24 GCC 3.5 "integration branch" David Edelsohn 2004-01-21 0:00 ` Geoff Keating @ 2004-01-21 10:22 ` Momchil Velikov 2004-01-21 14:56 ` Paul Jarc 1 sibling, 1 reply; 6+ messages in thread From: Momchil Velikov @ 2004-01-21 10:22 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.5 "integration branch" 2004-01-21 10:22 ` Momchil Velikov @ 2004-01-21 14:56 ` Paul Jarc 0 siblings, 0 replies; 6+ messages in thread From: Paul Jarc @ 2004-01-21 14:56 UTC (permalink / raw) To: Momchil Velikov; +Cc: David Edelsohn, gcc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-21 14:35 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-20 18:24 GCC 3.5 "integration branch" David Edelsohn 2004-01-21 0:00 ` Geoff Keating 2004-01-21 1:27 ` Joe Buck 2004-01-21 7:15 ` Paul Jarc 2004-01-21 10:22 ` Momchil Velikov 2004-01-21 14:56 ` Paul Jarc
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).