 Need to do a post about KC election results
 Congratulate re-appointees, and welcome Drain to the KC
 Congratulate re-appointees, and welcome Darin to the KC
[16:33] <mparillo> Rick has a draft: https://kubuntu.org/wp-admin/post.php?post=4925&action=edit
 Yes I drafted one, just needs a review and publishing I think
 Thanks (re @Rick_Timmis: Yes I drafted one, just needs a review and publishing I think)
 @ahoneybun I want to know what our account status is. Must be running out or even have run out
 Let me look
 At the moment we are not using linode for much
 Are we not building anything?
 Looks like we have $0.20 in credit?
 Not on their anymore since new ruby killed off our CI tooling (re @ahoneybun: Are we not building anything?)
 Mm not sure where the sponsorshopt would be.
 Not on there anymore since new ruby killed off our CI tooling (re @ahoneybun: Are we not building anything?)
 Not sure whether to ask for another year, or end it
 Well if we aren't using it. Where's the CI now?
 We don't have one currently (re @ahoneybun: Well if we aren't using it. Where's the CI now?)
 Wait what
 How did we push out the latest Plasma?
 Using the CLI tooling?
 Likely locally
 By making some git tars before the release, and doing the packing for them. So when the real tars came, not much was needed (re @ahoneybun: How did we push out the latest Plasma?)
 Ah
 We still have Bytemark and Jenkins ?
 Yes, but it can't do much without working tooling. As said, new ruby broke it (re @Rick_Timmis: We still have Bytemark and Jenkins ?)
 Even Harald with the Neon CI had much trouble fixing that for the new ruby
 Hmm, that's a bummer because he wrote it Doh!
 What about Santa's tooling, or the Lubuntu CI ?
 Precisely. If he struggled, then ours was a dead duck (re @Rick_Timmis: Hmm, that's a bummer because he wrote it Doh!)
 Lubuntu is due to rewrite our CI
 https://irc-attachments.kde.org/f7742c17/giphy.mp4
 My schedule has an opening for about 23.04 dev cycle pre-FF. If we can rewrite one and just either stand up one instance or several of our own instances, that would be ideal
 To be awfully frank, I was kind of unsure about continuing with Jenkins as a platform
 Probably something more contemporary
 OK Do you have any code yet? Anything we could look at
 Gitlab ?
 Nope (re @Rick_Timmis: OK Do you have any code yet? Anything we could look at)
 KDE are trying to get away from it (re @Rick_Timmis: OK Do you have any code yet? Anything we could look at)
 OK
 Would not work for our purpose IMO (re @Rick_Timmis: Gitlab ?)
 They just retired their build.kde.org jenkins server
 I think KDE have a Gitlab though, am I right ?
 I think if we worked together and formed a common spec and implemented it in a more universal way (think Calamares, not Ubiquity >:P) we'd benefit from a common codebase
 KDE are using gitlab, but as Simon says, it doesn't suit all needs
 It's quite bloated... (re @RikMills: KDE are using gitlab, but as Simon says, it doesn't suit all needs)
 Lubuntu decided on GitTea, not GitLab, for that reason
 Yes it is very boated, I agree
 *GiTea?
 Anyway
 Well I am excited already it's written in Go
 We should schedule *one* meeting at the beginning between interested parties (willing to bet I can get at least Erich, Josh, and Rudra on board) to determine the scope, and the people who actually are interested and able to write the code can carry on and report back progress :P (re @tsimonq2: I think if we worked together and formed a common spec and implemented it in a more universal way (think Calamares, not Ubiquity >:P) we'd ben
 My day job is a Go shop
 Very nice! I can work with mostly anything (re @Rick_Timmis: My day job is a Go shop)
 NO PERL
 :P
 👍 (re @tsimonq2: NO PERL)
 The CI stages, are they Shell, Python ??
 /me has been tempted many a time to buy a case or five of Red Bull and rewrite debhelper and Lintian :P
 i.e How we script up our packaging
 Ruby for Kubuntu's, I think the contemporary tooling is Python, Lubuntu's was Python + Flask
 (Iirc) (re @Rick_Timmis: The CI stages, are they Shell, Python ??)
 OK, I'm cool with using Python, that would be a good sensible choice
 We have our Bytemark hosting, which has enough poke to run an instance of Gitea and several build containers
 Here's the thing tho...
 I think Python is good and readable, and great for prototypes, but the CI should be as low-overhead as possible (re @Rick_Timmis: OK, I'm cool with using Python, that would be a good sensible choice)
 Surprisingly enough I'm in favor of a compiled language...
 I think we might be able to get the Kubuntu Focus guys Mike, and of course Eric to help. I could definetly get Mike from KFocus to ameeting
 How about this...
 @Rick_Timmis Would you be interested in sending an email (or drafting one) to the KC and the LC about a meeting? And we can selectively invite other people (e.g. other flavors and Kubuntu Focus as we want)
 Or even perhaps ubuntu-flavors@lists.ubuntu.com and CC the two aforementioned parties...
 If you're busy or unsure what to say I can get to this tomorrow or so
 Sure, let me do a quick draft, I'll share it here first for comment, give me 10 minutes
 Thank you!
 Thoughts on this...
 Dear Kubuntu, Lubuntu council
 A recent discussion around the status of the Kubuntu CI build and package automation systems revealed that presently Kubuntu CI is non-functional, and in a poor state of repair.
 Evaluation and discovery reports from the KDE Neon project, who also run the same code base, has diagnosed the CI Tooling written in Ruby is badly broken, and very challenging to repair.
 Independently the Kubuntu community does not have the people with the skills and resources to achieve this.
 We would like to propose a meeting to discuss the potential for us to work across flavours to develop a share build service, that could be maintained and supported as a common approach to packaing,and building our various flavours of Ubuntu.
[19:39] <mparillo> Is there anything here? https://code.launchpad.net/~kubuntu-packagers/ka/+git/kubuntu-automation/+ref/master
 That is not CI tooling (re @IrcsomeBot: <mparillo> Is there anything here? https://code.launchpad.net/~kubuntu-packagers/ka/+git/kubuntu-automation/+ref/master)
 The only thing to add would be that Launchpad doesn't meet our current needs. While we use it for build services, we don't want to be locked to Launchpad for ephemeral CI builds (re @Rick_Timmis: Dear Kubuntu, Lubuntu council
 A recent discussion around the status of the Kubuntu CI build and package automation systems revealed that presently Kubuntu CI is non-functional, and in a poor state of repair.
 Evaluation and discovery reports from the KDE Neon project, who also run the same code base, has diagnosed the CI Tooling written in Ruby is badly broken, and very challenging to repair.
 Independently the Kubuntu community does not have the people with the skills and resources to achieve this.
 We would like to propose a meeting to discuss the potential for us to work across flavours to develop a share build service, that could be maintained and supported as a common approach to packaing,and building our various flavours of Ubuntu.)
 (We need something more modern to process things... even using Launchpad isn't ideal... again one of those things I'd love to speed up given the energy...)
 Neon is not broken, but does break frequently. Only sitter (master of ruby) keeps it going (re @Rick_Timmis: Dear Kubuntu, Lubuntu council
 A recent discussion around the status of the Kubuntu CI build and package automation systems revealed that presently Kubuntu CI is non-functional, and in a poor state of repair.
 Evaluation and discovery reports from the KDE Neon project, who also run the same code base, has diagnosed the CI Tooling written in Ruby is badly broken, and very challenging to repair.
 Independently the Kubuntu community does not have the people with the skills and resources to achieve this.
 We would like to propose a meeting to discuss the potential for us to work across flavours to develop a share build service, that could be maintained and supported as a common approach to packaing,and building our various flavours of Ubuntu.)
 And sitter is also the original author? (re @RikMills: Neon is not broken, but does break frequently. Only sitter (master of ruby) keeps it going)
 Not fun for bus factor....
 Yes
 Otherwise I'd say the email is good
 Kubuntu and Lubuntu in and of themselves don't have the resources currently
 OK, I'm just making some amends
 Thank you!
 I'll skip the launchpad bit, as I don't want to mix concerns. If we can just focus on getting a working build service I think that'll be easier to achieve
 Not too much changed...
 Dear Kubuntu, Lubuntu council
 A recent discussion around the status of the Kubuntu CI build and package automation systems revealed that presently Kubuntu CI is non-functional, and in a poor state of repair.
 Evaluation and discovery reports from the KDE Neon project, who also run mostly the same code base, said it is very challenging to maintain and  repair.
 Independently the Kubuntu and Lubuntu community does not have the people with the skills and resources to achieve this.
 We would like to propose a meeting to discuss the potential for us to work across flavours to develop a shared build service, that could be maintained and supported as a common approach to packang,and building our various flavours of Ubuntu.
 Cool, I'll send that shortly..
 Sorry, got caught up with something... yes all good
[20:47] <valorie> I'm happy to see this discussion happening
[20:47] <valorie> any chance of sitter attending as well?
[20:47] <valorie> or Scarlett?
[20:47]  * valorie is home for another hour or so....
[20:48] <valorie> then back to the cabin/zero internet