Merge 4.4.5

Bug #605059 reported by Loïc Minier on 2010-07-13
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Fix Released
High
Unassigned

Bug Description

When it is released, and that should be RSN, we need to merge FSF GCC 4.4.5 into our 4.4 branch.

Loïc Minier (lool) on 2010-07-13
Changed in gcc-linaro:
milestone: none → 4.4-2010.07-1
importance: Undecided → High
status: New → Confirmed
Marcin Juszkiewicz (hrw) wrote :

Current 4.4.4 Ubuntu gcc-4.4 packages are updated to 20100706 (svn r161892) by debian/patches/svn-updates.diff

Loïc Minier (lool) wrote :

Yes, but this patch will disappear when gcc-4.4 in Ubuntu moves to 4.4.5, so we need to move ASAP ourselves.

Am I right in thinking that this is done like so?

  bzr merge lp:~vila/gcc/4.4

I suppose, ideally we would want an incremental merge, one change at a time? Is there a way to do that?

Loïc Minier (lool) wrote :

Yes, bzr merge is the way to do it; if by "incremental merge" you mean keep all revisions, that's exactly what will happen -- just like for the merges we're doing when we merge topic branches (with multiple commits) into gcc-linaro with bzr merge.

I think we need to be careful of the points at which we merge. We could merge continuously, at random points, that's probably ok but makes life complex for downstreams like Ubuntu which will then apply our diff on top on a released tarball, possibly after applying an SVN update patch.

e.g. for Ubuntu it's either:
- we merge random revisions, Ubuntu takes the diff between latest FSF release we have merged and our latest release; things go well if Ubuntu is basing on the same FSF release, but the SVN diff can't be combined with ours; if Ubuntu uses newer or older FSF base, things might not apply
- we merge at precise FSF release points; it's as above, except SVN diff is likely to be applicable

Another way to avoid the issue would be for the Ubuntu update process to be a bit more complex, taking a SVN checkout + FSF tarball + Linaro tarball as inputs instead of creating the SVN diff and the Linaro diff independently.

So I'd rather have us follow FSF release points for now and discuss how to handle that with Ubuntu at the next occasion.

I think the way to merge all revisions up to 4.4.5 is, from a gcc-linaro 4.4 checkout or a topic branch based on it:
    bzr merge -r tag:gcc_4_4_5_release lp:gcc/4.4

Cheers,

On 14/07/10 17:41, Loïc Minier wrote:
> Yes, bzr merge is the way to do it; if by "incremental merge" you
> mean keep all revisions, that's exactly what will happen -- just like
> for the merges we're doing when we merge topic branches (with
> multiple commits) into gcc-linaro with bzr merge.

OK, that would be my preference.

> I think we need to be careful of the points at which we merge. We
> could merge continuously, at random points, that's probably ok but
> makes life complex for downstreams like Ubuntu which will then apply
> our diff on top on a released tarball, possibly after applying an SVN
> update patch.

I don't see how?

> e.g. for Ubuntu it's either: - we merge random revisions, Ubuntu
> takes the diff between latest FSF release we have merged and our
> latest release; things go well if Ubuntu is basing on the same FSF
> release, but the SVN diff can't be combined with ours; if Ubuntu uses
> newer or older FSF base, things might not apply - we merge at precise
> FSF release points; it's as above, except SVN diff is likely to be
> applicable

Ubuntu should diff our release against the baseline they intend to apply
it to. If they diff against anything else, then things will break -
they'd be doing it wrong!

Whether the 4.4.x elements are at the start of our history, at the end,
in the middle, or scattered throughout is irrelevant - once it's been
flattened into a release tarball, it all looks the same, and a diff
upstream will just skip over any and all bits in both.

> Another way to avoid the issue would be for the Ubuntu update process
> to be a bit more complex, taking a SVN checkout + FSF tarball +
> Linaro tarball as inputs instead of creating the SVN diff and the
> Linaro diff independently.

Again, it doesn't matter how a source tree is assembled, the Linaro diff
needs to be created against the tree it will be applied to, be that a
plain vanilla FSF release, or a conglomeration of patches.

> So I'd rather have us follow FSF release points for now and discuss
> how to handle that with Ubuntu at the next occasion.

Upgrading one FSF release at a time suits me. Those are the snapshots
they test, and problem revisions will have been fixed or reverted. I'd
suggest we'd need a good reason to do anything else.

> I think the way to merge all revisions up to 4.4.5 is, from a
> gcc-linaro 4.4 checkout or a topic branch based on it: bzr merge -r
> tag:gcc_4_4_5_release lp:gcc/4.4

So, you intend to collapse the entire 4.4.4 -> 4.4.5 history into a
single commit, and then use "bzr log --include-merges" if you want to
unpick it? I thought you said multiple commits?

Andrew

Loïc Minier (lool) wrote :

The problem is that Ubuntu has one base AND an update to latest SVN patch; I guess we have to disable this when the Linaro diff is to be applied.

Multiple commits: ah I see why you're asking. It's not a collapsed history, the merge commit is a meta-commit, encapsulating the individual commits. It's only the bzr log defaults which give you this sense of collapsedness :-)

"bzr merge" and creating a merge commit is the right way to do it, we can revert individual commits we merged if we need to.

On 15/07/10 09:40, Loïc Minier wrote:
> The problem is that Ubuntu has one base AND an update to latest SVN
> patch; I guess we have to disable this when the Linaro diff is to be
> applied.

No, the patch can only be applied to one base - this one just happens to
be composed of a tarball plus patch, but that's an internal detail. By
the time the Linaro diff is applied, it's just a source tree, like any
other.

The Linaro release must be diffed against the base it is to be applied
to. Anything else is asking for trouble.

Andrew

Michael Hope (michaelh1) wrote :

The next gcc-linaro release is 8 days away. If the FSF 4.4.5 release doesn't happen by, say, the 4th then we'll postpone merging it to 2010.09-0.

Michael Hope (michaelh1) wrote :

Deferred as 4.4.5 hasn't been released yet.

Changed in gcc-linaro:
milestone: 4.4-2010.08-0 → 4.4-2010.09-0
Michael Hope (michaelh1) on 2010-09-14
Changed in gcc-linaro:
milestone: 4.4-2010.09-1 → 4.4-2010.10
Michael Hope (michaelh1) on 2010-09-28
tags: added: merge
Michael Hope (michaelh1) on 2010-10-15
Changed in gcc-linaro:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers