CI for stable apps

[Harald Sitter]

seems my return key got the best of me, inline continuiation

On Wed, Apr 8, 2015 at 10:47 AM, Harald Sitter <sitter.harald at gmail.com> wrote:
> On Tue, Apr 7, 2015 at 4:33 PM, Scarlett Clark <sgclark at kubuntu.org> wrote:
>>
>>
>> On 04/07/2015 04:21 AM, Loïc Grobol wrote:
>>>
>>> On 7 April 2015 at 09:37, Harald Sitter <sitter at kde.org> wrote:
>>>>
>>>> I have however been pretty much the only person
>>>> adjusting things and packaging new things and writing tech around all
>>>> this which worries me greatly.
>>
>> Pft, I was helping lots and packaged alot of the applications.
>
> Indeed. I had no intention of lessening your work there.
>
> There is however a disconnect between what mostly everyone does i.e.
> package things once upstream throws out tarballs, with what I am doing
> and everyone else should be doing as well i.e. packaging things ahead
> of time and automate the hell out of everything else.
>
> We still do not have apps 15.04 packages despite all the kf5 based
> shebang being packaged and integrated. And I fear the reason for that
> is not scheduling or anything it quite simply is that doing a release
> is requiring too much time when it really should not. I said this the
> last couple of times on IRC when someone was being down because of the
> release effort: There should be no effort to be had. What should
> happen is you tell the CI to prep an upload and the CI should merge
> the correct branches into the correct landing branches and then build
> the packages and upload them and orchestrate it such that builds don't
> take 24 hours because launchpad's dep-wait-retry mechanic is running
> on a schedule.
> While this is on my todo it does have low priority right now, that
> does however not exclude anyone else working towards this.
>
> After all, that is the entire idea here:
> 1. CI all the things such that changes that require human tinkering
> get smaller compared to bundle releases ultimately spreading out the
> time investment over the development time of upstream's new version
> rather than balling up every 3 weeks making people work overtime which
> they then need

... 3 weeks of vacation to recover again, leading into the next release

> 2. spend newly gained idle time on automating more things
> 3. have more idle time
> 4. ???
> 5. retire in the Caribbean and get drunk on rum

It does require so much effort right now because the presently used
tools are organically grown hacks that evolved into things they
weren't meant to be. They are not test covered making every change
ever made cause problems in the next release, they are mostly not
error tolerant bailing out at any random moment making you repeat the
entire madness or manually hack your way towards an upload. And so on
and so forth.
They are not bad tools, the best of their days are behind them though.
They probably were glorious procedural scripts at some point, now
however they are a pile of hacks. Look at any two of the scripts
you'll either find blatant code copies or an ifelse-chain to
workaround one thing or another

The only way to get out of this funk is to stop accepting the status
quo and reinvent the way we do releases. Most foundation code to make
that happen already exists in some form or another in the CI tooling
repos. All that is needed is someone to start working on it ;)

(I might have started rambling half way through xD)

HS