Move ubuntu-core-config from bzr to github

to fit in better with the GH review proces, @zyga-snapd lets move lp:ubuntu-core-config over to https://github.com/snapcore/

The conversion itself should be harmless and quick. Two questions:

  • how do we want to call the new repository, is github.com/snapcore/ubuntu-core-config correct? It feels a bit too long for me, maybe just core-config. Can it live as a part of the core snap? Should it?
  • do we want to convert any tags / releases

i dont think it should be part of core snap, core-config shoulds about right
there are no tags/releases in the bzr tree either, i only recently converted it from deb-src to bzr so there is nothing to lose or add.

Okay, I’ll go ahead and make the conversion. We can always rename core-config to something else if we want to. Will you handle terminating the Bzr repository (or changing it to a git mirror instead?)

i’ll just kill the bzr repo … has not been of any use anyway

core is a snap while ubuntu-core is an aggregated image including that snap and much more. What are we talking about here? Given we already have the core snap in GitHub, and it has a configuration hook, I suspect that’s something else, and as such that’s a super confusing name for it.

it is the source of the deb package carrying all defaults for the core snap
the typical bit that gets regular changes is the writable-paths config in there, for which we want to use PRs in the future

Ok, done. We now have https://github.com/snapcore/core-config

We need to do some post clean-up operations:

  • I’d add a nice README.md file that tells everyone what this is about, where to file bugs and everything
  • I’d consider featuring this repository so that when you visit https://github.com/snapcore you instantly see it
  • We should also give it a short description (the one that is visible in at the top of the page)
  • If we choose to use github for bugs we need to open issues (probably default), otherwise we should close issues and give clear bug reporting instructions.
  • If this will be imported into launchpad to be used as a part of package building we should setup the import process and the packaging recipe
  • we may want to rename COPYING to LICENSE
  • we may want to add travis support (just kidding, we just want to :slight_smile:
1 Like

Can we move that into the core repository itself? That sounds very related and appropriate to be shipped together.

sure, technically we can git merge it together but I don’t know how it is built into final images.

i dont consider GH for bugs an option here, bugs in that package are usually in relation to other launchpad projects/issues.
a bug just against this package is a very rare case, it is usually an addon task for a filed bug.

it is used as deb package from the image PPA (with the obligation to be moved back into the archive in 18.04)

I’ll let you discuss this and once you have a clear action plan please tell me if I should merge the repositories and what else needs to happen.

well, i’m rather against mixing the package source with the live-build scripts, unless we can have multiple trees under the core category … after all this source still needs building of a deb package and upload while the core (live-build) tree is used directly.

1 Like

Okay, I think that’s fair, even because I’m hoping we can separate the image creation routine outside of the creation of the core snap itself.

Can we name it core-image then?

well, there are more packages:

initramfs-tools-ubuntu-core (holding the initrd setup for writable paths, mounting of core and kernel snap etc)
ubuntu-core-config (carrying all defaults and extra config files to make teh core snap work as rootfs)
ubuntu-core-meta (integrating with the greater image build seed setup and germinate to generate the list of packages)

that latter one wont be possible to easily go to GH due to the deep integration with the seed mechanism, but the two first ones should eventually be on GH … is something like https://github.com/snapcore/core-image/build-scripts https://github.com/snapcore/core-image/defaults https://github.com/snapcore/core-image/initrd possible perhaps ?

(i.e. a sub-tree)

Yes, that sounds good. Let’s please use core-build instead of core-image. That feels more obviously build oriented rather than runtime oriented.

I don’t think we can have multi-level repositories. Github has a $owner/$repo layout. I think we can just do github.com/snapcore/{build-scripts,defaults,initrd} Actual names are just examples obviously.

well, then probably “core-defaults”, “core-initrd”, “core-build”

Sorry, I wasn’t suggesting a multi-level repository. I’m suggesting putting that content inside the one repository, as normal directories.