Detailed Roadmap to 16.04 on Halium 7.1 and beyond

demokrit

Hi everyone, i'll try to keep this short:

Intro (Motivation)

First of all, i opened a new Topic (instead of using the old "Roadmap" Topic in the Forum) because i think that topic was about an "idealistic" roadmap = what do we want to have as a end-product. This Roadmap here is supposed to be a detailed list what needs to be done. And perhaps some links and stuff that might help. I'm not saying that the forum is the best place but i was under the impression that it is very hard to see where to help/begin and what is the status when there is talk about "moving to 16.04 base" or "basing on Halium 7.1".

@Developers please don't get this wrong but sometimes i am under the impression that some or all from the core team are working on all projects at the same time. This is no ones "fault" since we just don't have that many devs and i am very thankful for your work, however i think that for an optimal developement pace some focusing (aka a Roadmap ;-P) would help sometimes.

Why i think we don't have this already

I know that there are our github milestones for 15.04 and 16.04 here, however the tasks are

very unspecific
rather wishes than tasks

What is missing

AFAIK we don't have a real prerequisites list for a devices kernel and android base in the moment. This would help a lot since achieving this prerequisites would be tasks to each milestone. So to make a good Roadmap, we first need to know what needs to be done exactly. (Of course we cannot know all of this in advance).

Action Points

Identify what needs to be done exactly. (like what features are needed inside the kernel for systemd, for lxc, for apparmor? A first reference might be what canonical did inside "project avila - xenial kernel" to get a 16.04 base with systemd and snappy going?)
Decide which ones are "must haves" and which are "nice to haves"
Create big milestones out of this.
4.Set up some place to gather info material on this together

A Quick Sketch

Milestone 1 (Gathering Info for Roadmap)

Identify kernel features needed for Ubuntu 16.04 rootfs
1.1. Which features are needed for systemd? What's the earliest mainline version including these? (most phones have 3.4 or 3.10 based kernels so earlier would be better, IF newer, is there a backport available? Where is it?)
1.2. What version of apparmor needs to be inside the kernel? (Mainly needed for snappy i guess?!)
1.3. Check what canonical did to their images, see if we should reuse anything?
Identify kernel features needed for Halium 7.1 base ( I know, this should be on haliums roadmap but we need to adress this too)
2.1.What lxc features are needed? (different lxc features in different mainline kernels, e.g basic support was in 2-6 something, almost everything landed until 3-8 only unpriviliged containers landed in 3-12)
Identify all steps needed so Halium 7.1 and Ubuntu 16.04 interact nicely
Identify all steps needed to get Mir 1.0 (or 0.27) with yunit up-and-running.
4.1. Do we have to do anything ourselves? (since there is a mir-staging PPA and yunit devs are working on 16.04 themselves?)
4.2 Will there be any ABI/API breakages we have to consider?
What steps will be involved in transition of apps/frameworks to 16.04?
5.1. Should we move to snaps? Alternatives? Consequences for each decision?
5.2. Do we have to build the frameworks and distribute them somehow? How?
...

Milestone 2 (Setting Prioreties and Set Up Infrastructure)

Set Prios to tasks gathered in Milestone 1, perhaps even state expected difficulty
Set up some place devs can gather links/info without doing shiny documentation around this
Tell the docu people to keep an eye on that place and merge important stuff into docu.
Get started with most important tasks.
4.1 Important assign who is looking into what!

Milestone 3 (Booting 16.04 rootfs with Halium 5.1 base)

Dont't know what is needed here...

Milestone 4 (Getting display server + everything else to work on 16.04-H5.1)

Dont't know what is needed here...

Milestone 5 (Move to Halium 7.1 base)

Dont't know what is needed here...

The bad news...

... is that this needs to be done by our core devs because only they will know what exactly what needs to be done (i guess?).

Outro

This is not meant as an attack on anybodys behaviour so far or the state of documentation or anything, just some ideas i had that i wanted to share and would like to hear your thoughts about it.