17:00:33 <bowlofeggs> #startmeeting Bodhi stakeholders (2018-12-18)
17:00:33 <zodbot> Meeting started Tue Dec 18 17:00:33 2018 UTC.
17:00:33 <zodbot> This meeting is logged and archived in a public location.
17:00:33 <zodbot> The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:33 <zodbot> The meeting name has been set to 'bodhi_stakeholders_(2018-12-18)'
17:00:35 <bowlofeggs> #meetingname bodhi_stakeholders
17:00:35 <zodbot> The meeting name has been set to 'bodhi_stakeholders'
17:00:38 <bowlofeggs> #topic salutations
17:00:39 <adamw> .hello adamwill
17:00:39 <bowlofeggs> #chair bowlofeggs adamw kparal masta mboddu nirik puiterwijk Kellin
17:00:39 <zodbot> Current chairs: Kellin adamw bowlofeggs kparal masta mboddu nirik puiterwijk
17:00:39 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:00:51 <nirik> morning
17:02:11 <abompard> .hello2
17:02:12 <zodbot> abompard: abompard 'Aurelien Bompard' <aurelien@bompard.org>
17:02:30 <bowlofeggs> thanks for coming everyone, let's get this party started
17:02:44 <bowlofeggs> #topic announcements and information
17:02:45 * abompard will have to leave in about 30 min, sorry
17:02:46 <bowlofeggs> #info Bodhi 3.12.0 is the latest release https://bodhi.fedoraproject.org/docs/user/release_notes.html#v3-12-0
17:02:52 <bowlofeggs> #info abompard has been working on adding a CI test suite for Bodhi to streamline Bodhi's release process https://github.com/fedora-infra/bodhi/projects/5
17:03:02 <bowlofeggs> it might not go much longer than that
17:03:19 <bowlofeggs> i actually just deployed 3.12.0 to production about 30 minutes ago or so
17:03:42 <bowlofeggs> it's really a bugfix release, but technically i added a feature to fix a bug (BZs weren't getting updated reliably)
17:03:59 <bowlofeggs> i'm actually not 100% sure this will fix that BZ issue - it was just a suggestion from the BZ maintainer
17:04:20 <bowlofeggs> so it's a featurebug release
17:04:42 <nirik> to test that, can I remove a bug from a update and re-add it?
17:05:08 <bowlofeggs> nirik: yeah i think that would do it, but the problem is that it worked sometimes before anyway
17:05:38 <bowlofeggs> so if it works, that doesn't necessarily mean the problems was fixed :/
17:05:45 <bowlofeggs> we'll just have to wait and see if it keeps working
17:05:58 <bowlofeggs> oterhwise i'll have to talk with the BZ folks again to see if they have other ideas
17:06:14 <bowlofeggs> i personally feel there is a 70% chance this fixed it or so
17:06:22 <bowlofeggs> and even if it didn't, it's a better way to auth anyway
17:06:42 <nirik> yep
17:07:07 <nirik> FWIW, it did work
17:07:13 <bowlofeggs> cool, that's good to know ☺
17:07:14 <adamw> ...and there was much rejoicing
17:07:28 <bowlofeggs> i'm very excited about the integration suite work that abompard has been doing
17:07:55 <bowlofeggs> bodhi has a pretty decent unit test suite (with 100% line coverage and i think 97-98% branch coverage [working on getting that to 100 too])
17:07:57 <abompard> thanks :-)
17:08:23 <bowlofeggs> but that doesn't catch some kinds of problems, so abompard has created an integration suite that runs a bodhi server and tests with with other components
17:08:45 <bowlofeggs> i think it currently tests the cli against the server for read requests, and uses the server with a live PG server
17:08:54 <bowlofeggs> it's early in the process, but very exciting
17:09:07 <bowlofeggs> i'm looking forward to be able to trust the tests more when i do releases
17:09:11 <abompard> no it runs PG in a container but downloads the latest DB dump
17:09:25 <bowlofeggs> yeah, i'd call that a live pg server ☺
17:09:30 <abompard> ah ok :-)
17:09:40 <bowlofeggs> the unit tests don't use PG at all - they use an in-memory sqlite
17:09:49 <bowlofeggs> so this is the only thing that tests us against PG
17:09:59 <abompard> alright
17:10:27 <bowlofeggs> anyways, abompard++ for taking that on - it's a huge project and he's made a lot of progress
17:10:27 <zodbot> bowlofeggs: Karma for abompard changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:10:33 <bowlofeggs> getting started is the hardest part anyway ☺
17:10:36 <abompard> thanks
17:11:10 <nirik> I thought the waiting was the hardest part... did tom petty lie to me?
17:11:42 <bowlofeggs> nirik: tom petty would never lie to you, but he might not have known much about software development
17:11:48 <bowlofeggs> and i'm freeeeeeee
17:12:02 <adamw> abompard++
17:12:02 <zodbot> adamw: Karma for abompard changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:12:02 <bowlofeggs> alright, let's talk about what i see in my crystal ball
17:12:17 <bowlofeggs> #info A Bodhi 4 is on the horizon, with backwards incompatible changes: https://github.com/fedora-infra/bodhi/projects/6
17:12:25 <bowlofeggs> so i actually started working on this one today
17:12:40 <bowlofeggs> it's a good time to do it, because it will let us KILL a lot of junk code in bodhi
17:12:59 <bowlofeggs> and that should help us go faster with the rawhide gating goal (we will talk about that in a few min)
17:13:16 <bowlofeggs> dropping python 2 is going to be so good (that's the ticket i'm working on today so far)
17:13:26 <abompard> amen to that
17:13:35 <bowlofeggs> i can finally use some of those cool python 3 features i've been drooling over for the past 10 years
17:13:54 <bowlofeggs> but there are a ton of backwards incompatible changes in there
17:14:11 <bowlofeggs> i wrote about this on the devel list, and so far nobody has objected to anything other than dropping critpath karma
17:14:17 <bowlofeggs> i'm fine with keeping critpath karma
17:14:27 <bowlofeggs> just want to make sure people think things we keep are useful
17:15:02 <bowlofeggs> i will be making backwards incompatible changes to the REST interface, because it doesn't actually follow REST ideaologies
17:15:03 * nirik isn't sure that is, but yeah, some people think so...
17:15:17 <bowlofeggs> i don't personally think it's useful
17:15:27 <bowlofeggs> but it doesn't cost me much to keep it honestly
17:15:31 <bowlofeggs> so it doesn't bother me too much
17:15:50 <Evolution> I'd very much like to do away with manual +1's
17:16:04 <Evolution> if we use it via automation for ci testing, fine
17:16:12 <Evolution> but too many people give bogus +1
17:16:40 <bowlofeggs> the +1s do serve some useful purposes at times, and there would not be a workaround if we removed it
17:17:08 <bowlofeggs> for example, adamw cited a process during branched composes by which people use +1s to make sure updates are marked stable that are in the compsoes
17:17:21 <Evolution> I don't think they can be removed until we have better/mandatory automated testin in place
17:17:23 <adamw> they are especially important during the freeze / release cycle, yes.
17:17:31 <bowlofeggs> we could make an admin button to force it, but it would be much more work to remove +1 and add that button than it would be to keep +1
17:17:32 <adamw> Evolution: this is not *remotely* a short-term goal, let's be clear on that.
17:17:37 <Evolution> absolutely
17:18:10 <bowlofeggs> i also do feel better about updates that have some +1s than i do about updates that just pass automated tests
17:18:17 <bowlofeggs> doesn't always mean much
17:18:24 <bowlofeggs> but warm feelings
17:18:44 <Evolution> yeah, but we all know the "worksforme" comments
17:18:52 <Evolution> hell, I'm guilty of leaving them
17:19:01 <Evolution> and been asked for them by devs looking to push something out quickly
17:19:03 <bowlofeggs> i actually have a topic on the agenda related to this for later, so i guess we could switch to that
17:19:15 <Evolution> ah, no if I'm jumping topics, I'm happy to wait
17:19:20 <bowlofeggs> #topic I plan to submit a proposal to update the updates policy
17:19:23 <Evolution> I just saw karma mentioned and jumped
17:19:37 <abompard> if people are exchanging +1s in Bodhi for services, it means they are using them as a digital currency and maybe then we can call lmacken back
17:19:51 <nirik> bodhi-coin!
17:19:55 <Evolution> ....
17:20:05 <Evolution> NEGATIVE BONUS MONEYS FOR nirik
17:20:06 <bowlofeggs> so i interviewed adamw a few weeks ago, and he and i talked about some ideas to improve the fedora updates policy
17:20:23 <bowlofeggs> i've been soliciting feedback from various stakeholders and have some notes on some ideas
17:20:44 <bowlofeggs> i haven't written it nicely yet for fesco, but i plan to open a fesco ticket in 2019 to see what we can do
17:21:12 <nirik> get ready for the flames. ;) But yeah, please do...
17:21:12 <bowlofeggs> one big thing i want to add is that autokarma will autopush when the update hits time in testing
17:21:34 <bowlofeggs> so for most packagers, you can just make an update and forget it unless someone -1's it
17:21:46 <bowlofeggs> -1's do disable autokarma
17:22:01 <bowlofeggs> +1 to bodhi-coin
17:22:16 <bowlofeggs> i've been trying to find a way to use the blockchain hammer on bodhi
17:22:24 <bowlofeggs> we need AI too of course
17:22:37 <adamw> ai-generated gating policies!
17:22:38 <nirik> 👍 is autopush on autokarmaed updates that hit the time.
17:22:59 <bowlofeggs> of course, gating is also going to be part of the proposal
17:23:05 <bowlofeggs> that still works terribly
17:23:15 <bowlofeggs> i have plans to just rip out the code that does that and do it again
17:23:26 <bowlofeggs> waiving is still very bad UX wise
17:23:52 <Evolution> is that something abompard could help with?
17:24:11 <abompard> I can help with implementing the UX, but we need someone to design it
17:24:41 <bowlofeggs> definitely, though we do need to make a decision about whether we want to keep using greenwave or not before working on that. honestly the separate services is a lot of why it's so hard to get this right
17:24:59 <bowlofeggs> i don't think it's necessarily bad design wise, it actually just doesn't work
17:25:08 <bowlofeggs> like it doesn't waive updates
17:25:20 <adamw> minor details!
17:25:22 <bowlofeggs> and it's so hard to work on because $microservices
17:25:29 <Evolution> do we have anyone from that team here for this?
17:25:52 <bowlofeggs> giulia_ seems to be hopping in and out of the channel
17:25:56 <bowlofeggs> i think she's from factory 2?
17:25:57 <Evolution> adamw: you're using greenwave for other things right?
17:26:12 <adamw> well, define 'using'.
17:26:25 <abompard> I think this stuff only works if you have a very reliable tasks queuing system that will retry stuff that fails and store status
17:26:50 <Evolution> my concern is that if we nuke greenwave from bodhi, but it's still being used by something else for gating, then we've fragmented systems
17:26:56 <adamw> there is a long-standing plan to use it for Rawhide *compose* gating (note: different from gating builds into Rawhide; this is about gating when we take a Rawhide compose and have it overwrite the 'live' content on the mirror network for 'rawhide')
17:27:12 <Evolution> adamw: so plan, but not implementation?
17:27:22 <adamw> let me verbate damnit :P
17:27:30 <Evolution> NEVAR
17:27:32 <Evolution> :-P
17:27:33 <bowlofeggs> abompard: i plan to do that too for bodhi 4! https://github.com/fedora-infra/bodhi/issues/2851
17:28:08 <adamw> the current status is that the greenwave policy exists and, as of last week or so, actually 'works', and my 'check-compose' thing that sends 'compose status report' mails to the mailing lists tells you whether the given compose passed the gating check
17:28:27 <abompard> bowlofeggs: nice!
17:28:29 <adamw> however, we are not actually *doing the gating*. we still just sync every rawhide compose that succeeds.
17:29:08 <adamw> but yeah, the intent is that we actually will do that gating. of course, if we decide to throw greenwave out, the compose scripts could just do that work themselves, like bodhi would have to do the update gating work itself.
17:29:33 <bowlofeggs> it's not that much work, which is why i was thinking about just doing it in bodhi
17:29:38 <bowlofeggs> bodhi actually already has the code to do it
17:29:44 <adamw> right now the idea is i think that there'll basically be a fedmsg listener which listens out for greenwave 'compose decision' fedmsgs
17:29:45 <bowlofeggs> and it's not a lot of code
17:30:01 <adamw> and when greenwave says 'oh hey a compose just passed the rawhide gating check!', it'll sync it.
17:31:02 <bowlofeggs> we should def talk more about this later, but i'd like to move on the next topic for this meeting
17:31:05 <nirik> it's hard to do the compose gating without the package gating.
17:31:07 <Evolution> bowlofeggs: thoughts on that? something you and adamw could agree on?
17:31:17 <adamw> without greenwave, i guess we'd have to write a new thing in releng which knew the policy, and a fedmsg listener that listened out for 'ci' messages indicating a test on a rawhide compose had just completed, and re-run the policy check every time that happens.
17:31:47 <bowlofeggs> Evolution: we do have a dedicated meeting to talk abotu this between you and adamw and I (and anyone else who is interested, let me know and i can invite you)
17:31:49 * abompard has to leave but will read the minutes
17:31:54 <adamw> so yeah, we can move on.
17:32:08 <bowlofeggs> thanks abompard!
17:32:29 <bowlofeggs> we don't necessarily have to use the same implementation of a thing here
17:32:38 <bowlofeggs> but yeah, let's talk more in a dedicated meeting
17:33:01 <bowlofeggs> but gating is the next topic!
17:33:02 <bowlofeggs> #info CI gating work, including Rawhide gating: https://github.com/fedora-infra/bodhi/projects/3
17:33:13 <bowlofeggs> so this has been hard to make progress on, due to resources
17:33:23 <bowlofeggs> i have gotten a few cards to move, but not much
17:33:37 <bowlofeggs> some of the work i plan for bodhi 4 is intended to support this effort
17:34:13 <bowlofeggs> for example, reworking the API to be RESTy will make it much easier to do an API for creating side tags
17:34:38 <bowlofeggs> i actually did start working on teh side tag API last week and was disgusted with bodhi's API code and just realized it'd be better to get it fixed first
17:35:13 <bowlofeggs> i don't plan bodhi 4.0.0 to have rawhide gating, to be clear. bodhi uses semantic versioning, so the 4 just means "watch out, things are changing and you will get wet, you may get soaked"
17:35:25 <bowlofeggs> so gating will probably happen in a later 4.y release
17:35:34 <bowlofeggs> but 4.0 will make it so much easier
17:36:22 <bowlofeggs> btw, that kanban is about more than rawhide - it's about all the things that are wrong with test gating that i know of so far
17:36:27 <bowlofeggs> rawhide cards are in there too
17:38:32 <bowlofeggs> any thoughts on gating stuff? shall i move on?
17:39:31 * nirik just wants the rawhide gating however we get there. ;)
17:39:43 <bowlofeggs> yeah i want it too
17:39:49 <bowlofeggs> i wish i had like 3 more abompards
17:39:52 <bowlofeggs> or 10
17:40:11 <adamw> yeah.
17:40:19 <adamw> i guess this is the one true plan for rawhide gating now, right?
17:40:32 <adamw> i recall there was some idea about doing it in pagure with co-ordinated pull requests, but i don't think i heard anything about that lately.
17:40:35 <bowlofeggs> i honestly spend a huge amount of time doing the boring maintenance work that isn't glorious, so i just don't have a ton of unused time to work on new features :/
17:40:46 <bowlofeggs> that's a lot of the goal of bodhi 4 to kill a lot of dumb code
17:40:50 <bowlofeggs> should speed me up a bit
17:40:53 <adamw> bowlofeggs: i think we can all say the same thing. :P
17:41:04 <bowlofeggs> adamw: yeah this is the plan afaik
17:41:08 <bowlofeggs> adamw: we def can
17:41:19 <adamw> (i just wonder why some people have enough time to write the new features that cause the rest of us to have to do all the boring maintenace...:D)
17:41:43 <bowlofeggs> EXACTLY!
17:42:20 <bowlofeggs> i was talking to a coder friend recently about how much time i spend just doing boring maitenance stuff, and in particular code review uses a lot of my time
17:42:28 <bowlofeggs> and he suggested it was kinda like a DOS
17:42:35 <bowlofeggs> you can DOS me by sending me features!
17:42:38 <bowlofeggs> hahaha
17:42:53 <bowlofeggs> it's the blessing and the curse of FOSS
17:43:08 <bowlofeggs> it's really awesome that people do this stuff, really
17:43:30 <bowlofeggs> people do some really cool stuff too
17:43:44 <bowlofeggs> mattia has been sending me lots of patches to fix up the new update form and i'm excited about that
17:43:54 <bowlofeggs> it's a nice improvemebnt
17:44:10 <bowlofeggs> alright, next topic
17:44:21 <bowlofeggs> #info Bodhi's high priority issues: https://github.com/fedora-infra/bodhi/issues?q=is%3Aopen+is%3Aissue+label%3A%22High+priority%22
17:44:24 <bowlofeggs> Are there any items that are not on that list that should be? Anything on that list that should not be?
17:45:11 <nirik> was there still one for the automating pushes? (which we already did)
17:45:31 <bowlofeggs> oh yeah that is done
17:45:35 <bowlofeggs> i dunno, lemme see
17:45:59 <nirik> https://github.com/fedora-infra/bodhi/pull/2670
17:46:03 <nirik> and it's merged
17:46:13 <bowlofeggs> cool
17:46:26 <nirik> ha no, it was cllosed due to inactivity
17:47:20 <nirik> but it's not clear to me why we needed it
17:47:39 <bowlofeggs> oh yeah
17:47:43 <bowlofeggs> so i do still want that
17:47:56 <bowlofeggs> basically bodhi-push --resume will resume ones that are currently running, which is not great
17:48:07 <bowlofeggs> but mboddu's automation does check for running composes
17:48:12 <nirik> true, but thats only run by a human, who we can yell at
17:48:14 <bowlofeggs> so it won't be bad given his implementation
17:48:21 <bowlofeggs> but i still think it should not be willing to do that
17:48:26 <nirik> his thing doesn't resume at all I don't think
17:48:28 <adamw> let's call it 'human ai'
17:48:30 <adamw> sounds better that way
17:48:32 <bowlofeggs> yeah it doesn't
17:48:34 <bowlofeggs> adamw: haha
17:48:48 <bowlofeggs> i don't think we need it for the automated pushes thing
17:48:55 <bowlofeggs> i just want it for the "this is wrong if you do that" thing
17:49:00 <nirik> ok. yeah, agreed
17:49:15 <bowlofeggs> i did think we needed it before i saw mboddu's implementation
17:49:27 <bowlofeggs> but he does query to see if there are compsoes before starting any, so that's ok
17:49:45 <bowlofeggs> i guess there's a tiny tiny race condition there, but meh
17:50:12 <bowlofeggs> #topic open floor
17:50:17 <bowlofeggs> anything else?
17:52:25 <bowlofeggs> #endmeeting