Include glamkit-* repos inside icekit and retire them

[cogat]

Coordinating dependencies is a pain and costs developers a lot of time. Given how often the glamkit packages are included in icekit, and the underlying strategic direction, it makes sense in the medium term to include them directly.

[cogat]

Specifically: glamkit-events glamkit-collections and icekit-press-releases. If we could include while preserving commit history that would be ideal, perhaps with git subtree or the like.

[jmurty]

One important outcome of this consolidation should be that running unit tests in django-icekit (especially in Travis) should run tests of all the subsumed projects as well. So we need to be sure that the events, collections etc tests are included in test runs once the repos are included, if it doesn't happen automatically.

[cogat]

From a chat with Aram:

[3:50] if you're confident that re-merging will never be necessary, the solution is quite simple: add icekit as a remote to the events repo, and push the master branch to a new branch on the remote and then pull on icekit, check it out, adjust directories, etc, then merge into one of the icekit branched, e.g. master

[3:53] so, in events: git remote add icekit <url of icekit repo> git push master icekit:events then in icekit: git pull git checkout events [adjust directory structure, etc] [commit the changes] git checkout master git merge events

[cogat]

Proposed plan (one repo at a time):

1) Carry out Aram's instructions above 2) Remove write access to the old repo 3) Audit which projects need to be updated, and do if trivial (AFAIK it's just ACMI, AGSA, arts-on-tour that use this version of ICEkit?), or make a plan if not.

[mrmachine]

We might also want to push any other interesting but not yet merged feature branches from icekit-events etc. into django-icekit?

[jmurty]

I'm reluctant to raise this, but should we take the chance during this inevitably disruptive process to also rename the repo/project to django-glamkit?

[mrmachine]

I don't think renaming the GitHub repo will be an issue, now or down the track. GitHub handles redirects automatically pretty well. But I think that for now, we should leave it as-is.

Unless we go all out and rename the Python packages as well, which will be much more disruptive (and I think, unnecessary), there is still going to be a "what's ICEkit?" question from anyone who actually looks at the code. And for everyone who doesn't look at the code, we just talk about GLAMkit and all our marketing material just talks about GLAMkit.

I think this ticket is just about reducing our effort in keeping multiple package versions in sync.

[cogat]

Unless we go all out and rename the Python packages as well

Those packages will be retired after this ticket is done...

[mrmachine]

There are two types of package and I think we're getting them confused.

The icekit Python package in this repo won't be retired or renamed after this ticket is done, to avoid significant disruption for very little practical gain. And likewise, the Python packages being vendored into this repo (e.g. icekit_events) should not be renamed.

The individual installation packages on PyPI (e.g.icekit-events) should be retired.

I think the Python package icekit_events (continuing the example) should become a top level directory in the ic-labs/django-icekit repo, and it should be installed into site-packages when django-icekit is installed (from PyPI or via editable VCS link in requirements.txt).

The contents of the icekit-events/docs folder should be merged with the top level django-icekit/docs folder. Dependencies listed in icekit-events/setup.py should be merged with dependencies in django-icekit/setup.py in this repo. Maybe as an extra?

[cogat]

I’ve merged the merge-repos branch into ICEkit’s develop branch. This is your cue to stop using or committing to glamkit-collections, icekit-events, glamkit-sponsors and icekit-press-releases as they’re all in ICEkit as standard. The last ICEkit develop revision before the merge is 8a3dbb, tagged pre-repo-merge. (edited)

I’ve brought across the main and unmerged branches of each of those repositories into new branches called c/[repo]/[branch].

  collections/5-refactor-edtf-fields
  events/feature/4-all-day-and-timezone-fixes
  sponsors/test-supported-versions

Remaining steps:

• make repos read-only
• bring across tickets
• release, and retire PyPI packages (how?)