Code review comment for lp:~sil2100/livecd-rootfs/core-series-per-suite

You are right regarding some problems with this approach. I think ubuntu-image should be good-enough in xenial for building images (we'd have to check if the deprecated mkfs.ext4 doesn't mess with the final filesystem too much) as I'm testing build and boot capabilities for amd64 with every release, but livecd-rootfs is completely outdated there. I didn't expect it to be missing even the basic ubuntu-image support.

Currently I see four ways of resolving this:

1) Making sure xenial-generated ubuntu-image images are ok and backporting livecd-rootfs changes for u-i and core series selection to xenial.

2) Switching to a new, separate environment parameter to steer which core series to use.

3) Using a different environment parameter from the existing ones to decide the core series. We could, potentially, use for instance SUBPROJECT. Currently for core images it's not used and maybe core series could somewhat fit that purpose? Hard to say.

4) Ugly but easiest way: deciding that we'll be using bionic for core16 and cosmic+ for core18.

I have prepared an MP for 1) [1], but I somehow suspect that this approach might be a bit troublesome. 2) seems like a bad idea, I remember no one actually wanted a new variable. We've got enough of those already. 3) might be good but this all depends on what uses we have for SUBPROJECT - or maybe there's a different variable we can use?

Lastly, there's 4). It's the easiest as it will not require much changes anywhere. The problem I have with it personally is that it's quite non-intuitive. Like, the binding that bionic -> 16 and cosmic+ -> 18 has no real basis anywhere and someone new, trying to build a new image, might just build the wrong thing.

Personally I'd prefer 3) or 4). What do you think? Which way should we go?

[1] https://code.launchpad.net/~sil2100/livecd-rootfs/xenial-ui-support-and-core-suite/+merge/356150