Merge https://github.com/eclipse-equinox/equinox.framework into https://github.com/eclipse-equinox/equinox.bundles

[akurtakov]

I'm opening this one as a tracking issue as the question why we have so many repos and how have we decided to split them up comes too often.
@tjwatson I'm leaving this for you :)

[vogella]

PMC decided that this repo should be merged into the equinox.bundles. Would be nice to get this either done in M2 or in early M1 for the next release.

As @HannesWell is currently very active in cleaning up the dead code in Equinox we should also wait for this activity.

[HannesWell]

Just for curiosity:
Why is this equinox.framework merged into equinox.bundles and not the other way round?
From my understanding this repo is the more basic one? Is it because besides o.e.osgi, its tests and the launchers (which hopefully becomes simpler too) it only contains plug-ins that are obsolete (sooner or later) like o.e.osgi.util, o.e.osgi.services and o.e.osgi.compatibility.state?

As @HannesWell is currently very active in cleaning up the dead code in Equinox we should also wait for this activity.

Thank you. :) I try to be as fast as possible but I'm currently slowed down by some unexpected problems with prelinary work I would like to complete for that.

And for clarification with next-release you mean 2022-09?

[vogella]

Just for curiosity: Why is this equinox.framework merged into equinox.bundles and not the other way round?

@tjwatson suggested that. And see eclipse-equinox/equinox.bundles#18 for a rename of equinox.bundles to equinox

[bjhargrave]

I assume you will do a full merge with complete history? So no history will be lost?

[tjwatson]

I assume you will do a full merge with complete history? So no history will be lost?

Yes, we must preserve history which has been accomplished for other merged repositories.

Why is this equinox.framework merged into equinox.bundles and not the other way round?

I don't think it is that important which is merged into which as long as the full history is preserved. The reason I suggested framework->bundles is because we were discussing which repo name should "survive" the merge. And during that discussion I said that "bundles" makes more sense than "framework". But then we decided that the final merged repo would just be renamed to "equinox" anyway so in the end it will not matter which gets merged into which.

[tjwatson]

@vogella How does this work for all the tags and branch names we have? I don't see we preserve all the maintenance branches or tags. How was that done for the other repos you merged?

[bjhargrave]

Yes, we must preserve history which has been accomplished for other merged repositories.

I have done such a repo merge with history preservation myself with bnd+bndtools -> bnd.

[bjhargrave]

How does this work for all the tags and branch names we have?

You will probably need to retag the dying repo to use non-conflicting tag names before you merge it into the surviving repo. You can't have the same tag pointing to different commits.

[vogella]

We typically merge the master branch into the master branch of the target. The old repo is still there so tags and maintenance branches will remain there.

@bjhargrave why (and how) did you merge all maintenance branches into each other? What is the value, old builds did happen against the old repo so merging the maintenance branches together results in a wrong picture IMHO.

[bjhargrave]

The two repos will need disjoint branch and tag name sets before merging. This could be done by modifying (a clone of) the dying repo to change all branch and tag names to be different than the surviving repo. Then when the dying repo is merged into the surviving repo, all the branch and tag names are present.

So the repo whose branch and tag names should not be changed should be the surviving repo.

So using the branch name R4_23_maintenance as an example, in the dying repo, it must be changed to something like R4_23_maintenance_framework before being merged into the surviving repo which already has a R4_23_maintenance branch. Same for tags like I20220421-1910 which exists in both repos. There are a lot of tags...

A much more complicated and aggressive approach would be to attempt to actually merge the contents of the repos at each branch and tag having the same name. But that would be a complete rewrite of all commits and a non-fast forward push. That seems too much.

[bjhargrave]

The old repo is still there so tags and maintenance branches will remain there.

We if you only care about the main branch, then you can ignore all the tags and branches. But it does effectively mean some history is lost in the surviving repo since you will need to know to look in the archived, dying repo.

[vogella]

Except the merged repo is not dying, it will remain available only new development will be done in the new repo. So doing the work you sugggesting will like a lot of effort visible benefit (for me), as all the old info is still available via the old repo.

[bjhargrave]

Except the merged repo is not dying,

It should be marked "Archived" in GitHub to make it read-only to all and to clearly indicate to viewers its status.

[vogella]

Except the merged repo is not dying,

It should be marked "Archived" in GitHub to make it read-only to all and to clearly indicate to viewers its status.

+1, if that is possible to mark it as Archive.

Still the history will be available. I belong in the "old stuff is not valuable enough to spend a lot of effort to save it" camp so I think we should not spend a lot of effort on moving old info to new places. If people want to find out what went in a maintenance release, they can check the old repo.

[vogella]

@tjwatson any progress on the merge side?

[laeubi]

@tjwatson please get in contact with EF Infra to archive this repository now!

[vogella]

@tjwatson please get in contact with EF Infra to archive this repository now!

AFAIK we still need this for maintenance builds, you can empty it (delete everything and create README about the move) similar to the PDE.build or eclipse.platform.runtime repo if you want.

[tjwatson]

I can take care of the README and delete from the main branch. I was waiting for a good I-Build to happen on the new repo before I did that. AFAIK we have not had one yet?

[akurtakov]

@tjwatson please take care of cleaning the old repos now. We have an "almost" successful build aka with comparator errors https://download.eclipse.org/eclipse/downloads/drops4/I20220616-0910/ but that's independent of the merge.

[vogella]

#73 for https://github.com/eclipse-equinox/equinox.framework/

[vogella]

eclipse-equinox/equinox.bundles#60 for https://github.com/eclipse-equinox/equinox.bundles

[vogella]

Done, thanks @akurtakov and @laeubi for doing the work for this. Interessting how fast things can move once something breaks like the Maven update. :-)

[HannesWell]

Thanks, also from me to @laeubi and @akurtakov!