Create Task
Maniphest T3721

LTS
Closed, ResolvedPublic
Actions

Description

Plasma 5.8 is LTS we want it to be a new neon type as well.

Mix

  • LTS Ubuntu
  • Latest Qt
  • Latest frameworks
  • LTS plasma
  • Latest Apps and Extras

Archives

  • dev/stable/lts/plasma (from-branch build; variation of stable)
  • user/lts/plasma (from-tar build; variation of release)

Git Branches

  • Neon/stable/LTS
  • Neon/release/LTS

(merged standalone, release->stable) interaction via regular branches *only* through manual cherry picking.

Build job names

  • xenial_stable-lts_plasma_*
  • xenial_release-lts_plasma_*

Composition

We could compose LTS systems out of their base repo (dev/stable or user/) and simply stack the LTS stuff on top. Which would substantially cut down on tooling changes, build time impact and overall system complexity.

This would require LTS builds to be strictly greater versioned than their non-LTS counter-parts, or an apt priority config (i.e. a pin) at run and build time to make sure whenever a dep can be gotten from the LTS repos, it is obtained from there regardless of what is in the non-LTS repo!

Concerns

  • with everything being on latest other than plasma, things could very well break as things move about in the stack
  • there is an excess amount of publishing hacks, qa hacks, multi-builds caused by the lack of T3407 which would be blown up by adding another permutation
    • failing to update one of the hacks in the tooling would also result in breakage, or inconsistent results

Related Objects

sitter created this task.Sep 13 2016, 1:06 PM
sitter updated the task description. (Show Details)Sep 22 2016, 11:02 AM
sitter updated the task description. (Show Details)Sep 22 2016, 11:06 AM
jriddell added a subscriber: jriddell.Sep 22 2016, 1:33 PM

Mix: Qt has Qt 5.6 LTS, should we use that?
There's rumours of a Frameworks LTS release with cherry-picked fixes, should we use that?

Is there enough use case to justify the effort for dev/stable/lts/plasma ?

"We could compose LTS systems out of their base repo (dev/stable or user/) and simply stack the LTS stuff on top. " This seems illogical, LTS stuff will have a lower version number than non-LTS stuff, keeping it higher seems dangerous and playing with pin files is always dangerous.

where to put in merge sequence -> release/LTS -> stable/LTS -> release -> stable -> unstable

sitter added a comment.Sep 22 2016, 1:52 PM
In T3721#55954, @jriddell wrote:

Mix: Qt has Qt 5.6 LTS, should we use that?

Why would we? Who would maintain that?

There's rumours of a Frameworks LTS release with cherry-picked fixes, should we use that?

Why would we? Who would maintain that? Worse yet. This would not bet cherry-picked into a public branch, so we can't even CI this properly.

Is there enough use case to justify the effort for dev/stable/lts/plasma ?

How would we develop a !dev version if there is no dev version? Oo

"We could compose LTS systems out of their base repo (dev/stable or user/) and simply stack the LTS stuff on top. " This seems illogical, LTS stuff will have a lower version number than non-LTS stuff, keeping it higher seems dangerous and playing with pin files is always dangerous.

So how do we deal with the fact that everything needs to be built 2 more times?

where to put in merge sequence -> release/LTS -> stable/LTS -> release -> stable -> unstable

I don't think stable/LTS can rank before release. If stable/LTS for example moves a file that would break release. So IMO this could only be release/LTS -> release -> stable/LTS -> stable -> unstable. That however means that release can break things, so I think this really are two merge chains

  • release/LTS -> release -> stable -> unstable
  • release/LTS -> stable/LTS -> stable -> unstable

Since that creates some 6 chances for invidiual merge conflicts I am not sure that makes sense either. And instead we should simply cherry pick into LTS and keep it out of the merge chain?

How do we deal with conflicting information (in particular debian/watch) if we put it in the merge chain?

jriddell added a comment.Sep 22 2016, 2:09 PM

"We could compose LTS systems out of their base repo (dev/stable or user/) and simply stack the LTS stuff on top. " This seems illogical, LTS stuff will have a lower version number than non-LTS stuff, keeping it higher seems dangerous and playing with pin files is always dangerous.

So how do we deal with the fact that everything needs to be built 2 more times?

Indeed. As Plasma is the only different build here is there some way to separate out those builds?

where to put in merge sequence -> release/LTS -> stable/LTS -> release -> stable -> unstable

I don't think stable/LTS can rank before release. If stable/LTS for example moves a file that would break release. So IMO this could only be release/LTS -> release -> stable/LTS -> stable -> unstable. That however means that release can break things, so I think this really are two merge chains

  • release/LTS -> release -> stable -> unstable
  • release/LTS -> stable/LTS -> stable -> unstable

    Since that creates some 6 chances for invidiual merge conflicts I am not sure that makes sense either. And instead we should simply cherry pick into LTS and keep it out of the merge chain?

    How do we deal with conflicting information (in particular debian/watch) if we put it in the merge chain?

Yes having them just release/LTS -> stable/LTS and cherry-pick from normal branches as needed seems simplest

sitter added a comment.Sep 27 2016, 1:01 PM
In T3721#55962, @jriddell wrote:

Indeed. As Plasma is the only different build here is there some way to separate out those builds?

See description "there is an excess amount of publishing hacks, qa hacks, multi-builds caused by the lack of T3407 which would be blown up by adding another permutation"

sitter updated the task description. (Show Details)Sep 27 2016, 1:02 PM
jriddell claimed this task.Nov 14 2016, 5:22 PM
jriddell moved this task from Discussing to Doing on the Neon board.
jriddell added a comment.Nov 28 2016, 11:01 AM

one adds a new type to ci-tooling/data/nci.yaml, one adds a new projects yaml to the projects repo, one mass creates relevant branches, one runs the updater

also grep -r qt and update all weird hacks where qt is being pushed into multiple repos

jriddell added a comment.Jun 16 2017, 11:08 AM

time to close this card I think

Do we want a dev/stable/lts edition? My feeling is that's too much work for not enough gain, there doesn't seem to be much demand for it.

jriddell moved this task from Doing to Review on the Neon board.Jun 16 2017, 11:08 AM
bshah closed this task as Resolved.Jul 17 2018, 6:31 AM
bshah added a subscriber: bshah.

Should be closed now.