[Kubuntu Automation] Operation Fir Tree

[Philip Muskovac]

Hey,

regarding the library packaging, how about merging the automation tools
back into our kubuntu-dev-tools [1]?
That's the repository that has our general purpose development tools,
has existing and working debian packaging and already supports python
lib installation.
With that we could then deprecate the entire automation repository
as that's only a separate entity because it also contains all those static
config and data files.

Having 2 seperate tooling packages that are both installable and serve
kind of similiar purposes is rather confusing IMO.

[1] https://code.launchpad.net/~kubuntu-packagers/kubuntu-dev-tools/trunk

Am 19.04.2017 um 11:03 schrieb José Manuel Santamaría Lema:
> Hi,
>
> I have in my technical agenda various "black operations" related to Kubuntu
> Automation for Zesty+1. The first one I would like to complete is "Fir Tree".
> https://phabricator.kde.org/w/kubuntu/black-operations/fir-tree/
>
> Why?
> Because getting this one will allow me to make future changes in KA without
> interrupting the work of the rest of the team. For instance, I will need to
> rework again the 'kubuntu-retry-builds' script  to share its code with 'ka-
> iron-hand' because of:
> https://phabricator.kde.org/w/kubuntu/black-operations/iron-hand/
> While doing that, I might break that script by accident, so to do that kind of
> work it would be nice to have a stable version of KA which people can use
> without suffering disruptive changes and an unstable version where we would be
> free to add features, rework bad code[1] and test any kind of innovation in
> advance.
>
> However, while we go trough the Operation Fir Tree, we are going to get some
> slightly disruptive changes (don't worry, it's not a big deal). There's no
> other way around this:  with the current KA code, we can't have stable KA
> versions[2] so this is a "chicken and the egg" problem. The good news is that
> once we are done we will - hopefully - enjoy some KA stability.
>
> What is going to change from the user point of view in KA?
> 1. The way to install Kubuntu Automation
> 2. The setup we have on the server providing the status pages (I don't have
> access to that server by the way)
> (as I said, not a big deal)
>
> That being said, I would like to work with you all on all of this the next
> weekend during the devel meeting if that's possible. I will need your help,
> feedback and cooperation, so thank you in advance.
>
> [1]Keep in mind that most of KA code is not bad because people who worked on
> it did a bad work. It's bad because they code was written in a hurry to get
> the packages released (which is what our users actually use, KA is just an
> internal tooling for us). So they are many things which are cheap solutions
> which should be replaced with better solutions. For instance the ppa-build-
> status script is getting the work done, but the code is awful, unnecesarily
> difficult to maintain and ineffcient.
>
> [2]As I already explained some time ago here:
> https://lists.ubuntu.com/archives/kubuntu-devel/2016-November/010941.html
>