Quantcast

[Kubuntu Automation] Operation Fir Tree

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Kubuntu Automation] Operation Fir Tree

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

--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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
>


--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Kubuntu Automation] Operation Fir Tree

José Manuel Santamaría Lema
El jueves, 20 de abril de 2017 15:15:33 (CEST) usted escribió:

> 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

Hi Philip,

thanks for your input. So the "Operation Coherence" was born :P
https://phabricator.kde.org/w/kubuntu/black-operations/

Because now that you mention it, I wanted for a while to import the
kopypackages script in KA, make a few changes and rename it as kopypackages2.
So I agree that we should merge both KA and KDT in the future. However, note
that...

1. to make that move feasible, first of all we need to complete the Operation
"Fir Tree" (skipping the package renaming). The current KA scripts still need
a few changes to make them work properly if installed from a package. I expect
to finish and test thoroughly these changes in a few days. I already have an
experimental package here:
https://launchpad.net/~panfaust/+archive/ubuntu/ka-exp
and some changes which I didn't push to the official KA git repo here:
https://code.launchpad.net/~panfaust/ka/+git/ka/+ref/fir-tree
and a separate repository for the metadata here:
https://code.launchpad.net/~kubuntu-packagers/ka/+git/ka-metadata
This work needs to  be completed no matter what, because without it any kind
or merging with KDT would be impossible.

2. while I agree we should merge both toolings I would really prefer to merge
the KDT bits which are still useful into KA and not the other way around,
because that's going to result in less work to do. KA is more actively
mainatined and it provides most of the tools we are using today to provide new
software in the PPA's and the archive. KDT, on the other hand, is still in bzr
and afaics several python scripts are still using python2, they are also
various things which are clearly obsolete. In any case we have to check all
the scripts in KDT and see what's obsolete, what needs to be updated and
what's still useful.

That being said, regarding the KDT packaging, last time I used the
kopypackages script I had to build the package myself because I din't find it
already built anywhere. So I would like to propose this:
* create a PPA here https://launchpad.net/~kubuntu-ppa named "Kubuntu
Developers"
* upload to that ppa the following packages for zesty and xenial:
- kubuntu-dev-tools
- ka-deps (as in https://launchpad.net/~panfaust/+archive/ubuntu/ka-deps)
- kubuntu-automation (as in https://launchpad.net/~panfaust/+archive/ubuntu/
ka-exp)

Cheers

--
kubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Loading...