search

blue-systems / plasma-5.5

Plasma 5.2 - 5.5
0 stars 0 forks source link

[packaging patches]: have a patches git repo for kubuntu/kci from which all patches are applied to each release (vivid, vivid+1,...) #100

Closed star-buck closed 9 years ago

star-buck commented 9 years ago

This would also serve as an overview if some patch is currently still missing, and which patches need to be applied when a fix is not merged upstream yet.

hsitter commented 9 years ago

Two questions:

  1. What's the priority of this / how urgently do we need this
  2. Why a git repo rather than a web page? For overview purposes a web page seems somewhat simpler to implement and use.
star-buck commented 9 years ago
  1. Prio is mid-to-high.
  2. I'm open to what fits best, just thought a git repo could help with automatic pull in the patches and apply them using branches (master = current release and in the future then a branch copy ("vivid") for historical reasons, like when we want to backport).
hsitter commented 9 years ago

Regarding repo vs. page what we could do is write code generating an html page but write it in such a way that we could then build a two-way-sync repo ontop of the same code base.

two-way-sync is probably going to be magnitudes more complicated and would require quite a bit of discussion first. Like, I am not sure one grand unified repository with patches is necessarily making things easier to manage. We'd essentially be detaching the packaging from the patches, which is fine for some patches and impossible for others. For example a patch that enables or disables a part of the build usually needs adjustments in the packaging as well.

What I would suggest as a long-term goal actually resembles what I have planned for streamlining release packaging. We'd have some piece of CI detect that we want a patch test-integrated (e.g. by filing a github ticket or for all intents and purposes we could place a file in a git repo describing how to get the patch). The CI system would automatically fetch the patch and create temporary integration branches from the relevant origin branches (master, vivid, vivid+1 etc.), applies the patch to all the branches and tries to build them in a (temporary) PPA. A human reviews the result and if it looks good the integration branches get merged and possibly the PPA builds get copied to some other PPA for additional testing or release. A web page would complement this for high level patch management overview and could then also drag in integration states and so forth.

Canonical is already doing something very similar to this: http://people.canonical.com/~platform/citrain_dashboard/ They are essentially having a whole bunch of PPAs called landing silos where their CI system automatically uploads proposed changes. It runs QA measures on the proposed change and if everything looks fine a human approves and gets it uploaded to the production archive.

Alas, unless we want to adopt the exactly same tech (which is from what I have seen pretty error prone and very tightly tied to launchpad) implementing the entire process is probably going to be a 3 to 6 month project. On the plus side we want something very similar for release packaging automation to get KDE releases packaged faster and more reliable and with less human involvement anyway, so the general underlying tech for all of this is already on my todo.

hsitter commented 9 years ago

I pretty much rewrote the current patch parsing tool we already had running for kubuntu to give it more coverage and improve its overall value.

http://qa.kubuntu.co.uk/~jr/patch-parser/kubuntu_vivid_archive.html

star-buck commented 9 years ago

a bit simplified would have been good, but okay.