This is the mail archive of the mailing list for the Archer 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: New branch for Fedora 11 merges

On Wed, 25 Feb 2009 18:32:54 +0100, Keith Seitz wrote:
> The big concern that I have about using separate branches is that both  
> Sami and I are touching the same parts of GDB (and not superficially,  
> either), and we may introduce patches on separate branches which may  
> interfere with each other later when merged.

Another possibility I am used to (well because Fedora/quilt work exactly this
way) is just to base the branch on top of the other branch.  But sure it is
something in between the fully separate and fully merged development, in both
the pros and cons - it is still separable but the top branch is not
submittable as is separately etc.

> I've already run into this with my two expressions-related branches, and  
> I believe that Sami has also run into this when he merged into the  
> expr-cumulative branch from his own branch.

The positive income is that once the problematic parts get merged the
continuous incremental development may +/- get imported the the merged-branch
for free.  But understood more significant changes still conflict.

I may be biased by the separate pathes of Fedora; AFAIK Debian uses a single
merged vendor patch for each package.

> [Hint: Are we going to have to allocate resources for one  person to
> continually merge "features/fixes" (branches) into a "release  branch"?]

Please note I do not find this as too much a problem of the merging effort.
It is more a problem of the disconnection from the valuable community testing
- the end users.  Implications of an end user problem get less and less
related to the original "blue skue" development branch as the problem may be
related to the merging glues no longer reproducible on the original branch.

Still to find out where the problem comes from means fixing it which means to
fix it first in the merged branch and later - sometimes completely differently
- in the "blue sky" original development branch.

This is the visible disadvantage of the Fedora fork from FSF GDB negatively
affecting both the projects.  Trying to prevent happending this again even
with Fedora vs. Archer.

It may be seen as I am contradicting myself above by both parts of the mail
but I hope it makes sense.


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