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: branch merging


On Nov 16, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     Actually speaking about branch.  Is there some plan how merging of
>     code from branches will look like?  The release schedule gives
>     relativly short period of time for branch merging and moves a lot of
>     code to branch.

>     We currently do have very active ast-branch, new-regalloc, Jeff is
>     working on Midlevel RTL/SSE and I've recently created the cfg-branch,
>     as disussed earlier.  (I've put the information about it to the web
>     pages soon).  I expect all these branches to make huge progress till
>     3.1 branching.

> This has also been my concern for a while.  The situation is likely to be
> made worse during the December 15 to February 15 period since people will
> then need branches to do *any* development work.

I believe the strategy is that developers don't focus in development
work, but in stabilization work, during this period.

> I can easily see the situation on February 15 to be one where we have a
> dozen branches, none of which have been keeping up with any other branch
> and some of which have been undergoing major development for over six
> months.  Merging all this into the top-of-tree seems to be a major job and
> I too am curious how all of this is supposed to be accomplished.

We could probably diminish the problem of merging multiple branches by
creating a single unstable branch, and having all development proceed
in it.  But then, this is equivalent to branching 3.1 earlier, in that
it wouldn't give incentive for us to focus in stabilization instead of
new developments.

But I somehow find it hard to picture myself not creating a branch and
delaying development work, be it part of my job or done just for the
fun of it, and focusing exclusively on stabilization of the tree.  I'd
like to think I'm not alone in this way of thinking, so we have to
discuss how to approach the problem to avoid complete disruption of
the release cycle during the stabilization period and immediately
after it, when all sorts of merges are deemed (or doomed :-) to take
place.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


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