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"


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


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