15:09:36 <trishnag> #startmeeting Bodhi stakeholder's meeting
15:09:36 <zodbot> Meeting started Tue Dec  6 15:09:36 2016 UTC.  The chair is trishnag. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:09:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:09:36 <zodbot> The meeting name has been set to 'bodhi_stakeholder's_meeting'
15:10:18 <trishnag> #chair bowlofeggs dgilmore puiterwijk nirik acarter
15:10:18 <zodbot> Current chairs: acarter bowlofeggs dgilmore nirik puiterwijk trishnag
15:10:36 <dgilmore> hola
15:10:43 <trishnag> hi
15:11:07 * trishnag goes to find meeting logs
15:13:32 <trishnag> #topic Action items from last meeting
15:13:54 <trishnag> * We will fix https://github.com/fedora-infra/bodhi/issues/1009 with 2.3.0
15:14:06 <trishnag> * comment on https://bugzilla.redhat.com/show_bug.cgi?id=1258532 that I need help maintaining the bodhi 1 CLI
15:15:09 <trishnag> https://github.com/fedora-infra/bodhi/issues/1009 is still on progress
15:15:58 <trishnag> bowlofeggs: has already update the ticket https://bugzilla.redhat.com/show_bug.cgi?id=1258532
15:16:16 <trishnag> #topic Bodhi 2.3.3 on Prod now
15:17:47 <trishnag> bodhi now uses Use krb5 for koji  :) https://github.com/fedora-infra/bodhi/pull/1129
15:18:04 <dgilmore> nice
15:19:40 <trishnag> Our major purpose now is to introduce non-rpm in Bodhi.
15:19:48 <trishnag> dgilmore: do you want to say anything on this?
15:21:15 <dgilmore> trishnag: not really at this point, I am still trying to catch up on things after two weeks PTO
15:21:47 <dgilmore> we need non rpm support
15:23:06 <trishnag> yes.
15:25:25 * trishnag waits for bowlofeggs if he has anything to say.
15:25:32 <trishnag> or anyone else :-)
15:27:25 <dgilmore> okay
15:27:35 <dgilmore> where is non rpm support at?
15:29:30 <trishnag> Here is the ticket for supporting non-rpm artifacts https://github.com/fedora-infra/bodhi/issues/653
15:29:56 <bowlofeggs> hello i am back!
15:30:03 <bowlofeggs> i'm very sorry for missing my own meeting
15:30:15 <bowlofeggs> i had a contractor over and he needed help lifting two heavy appliances
15:30:35 <trishnag> bowlofeggs: hi!
15:31:15 <bowlofeggs> dgilmore: the non-rpm support has been pushed back to F26 unfortunately
15:31:35 <bowlofeggs> dgilmore: i believe we made that decision in an acarter meeting ~1 month ago
15:31:51 <bowlofeggs> mostly because i didn't have time to do both that and the docker stuff
15:32:05 <dgilmore> bowlofeggs: sure, just curious how far along it is
15:32:09 <bowlofeggs> in hindsight, if i'd known i'd be blocked this long on the docker mirroring work, i'd have just done it
15:32:17 <bowlofeggs> dgilmore: it's not anywhere along ☹
15:32:32 <bowlofeggs> dgilmore: however, i have promised acarter that i'd have a plan by the end of february
15:32:38 <dgilmore> the issue is next to useless
15:32:46 <dgilmore> bowlofeggs: okay
15:33:01 <bowlofeggs> yeah that ticket doesn't say much
15:33:34 <bowlofeggs> i will say that i think it's been good that i've been not doing either of those things - it's meant more time working on bodhi bugs
15:33:54 <dgilmore> damn bugs
15:33:56 <bowlofeggs> bodhi still can't be described as "stable", but i think it is better than it was 2 months ago
15:33:59 <bowlofeggs> hahah yeah
15:34:22 <dgilmore> its okay bowlofeggs you can just go patch the code on the server, it will be fine
15:34:23 <bowlofeggs> but being able ot focus just on tightening up the spaghetti and duct tape i think was a worthwhile investment
15:34:29 <bowlofeggs> dgilmore: hahahahahah nooooooo
15:34:33 <dgilmore> :)
15:34:55 <bowlofeggs> actually,w e *still* don't have a release with the production code ☹
15:35:14 <bowlofeggs> even after the 2.3.3 release, there are i think two hotfixes on production
15:35:24 <bowlofeggs> so i am planning a 2.3.4 with those two fixes
15:36:02 <trishnag> awesome.
15:36:04 <bowlofeggs> i do have a gobby for this meeting
15:36:11 <bowlofeggs> i guess i could write that stuff in here now
15:36:34 <bowlofeggs> #topic Looking forward
15:36:46 <bowlofeggs> #info These are the issues highest on the Bodhi priority list https://github.com/fedora-infra/bodhi/issues?q=is%3Aopen+is%3Aissue+label%3ACritical
15:36:48 <bowlofeggs> #info There is also a high priority issue list https://github.com/fedora-infra/bodhi/issues?q=is%3Aopen+is%3Aissue+label%3A%22High+priority%22
15:36:49 <bowlofeggs> #info Critical means we can't go on living in this squalor
15:36:50 <bowlofeggs> #info High priority means it's important, but not a show stopper
15:36:52 <bowlofeggs> Any filed issues that aren't on these lists that should be?
15:38:08 <bowlofeggs> also, is there anything on these lists that you think should be lower priority?
15:39:28 <trishnag> bowlofeggs: what about this one? https://github.com/fedora-infra/bodhi/issues/1091
15:40:07 <dgilmore> bowlofeggs: https://github.com/fedora-infra/bodhi/issues/1138 I think should be hig priority
15:40:10 <dgilmore> high
15:40:33 <bowlofeggs> trishnag: yeah i think we can raise that to high since it's annoying. i'll mark it
15:40:39 <dgilmore> I think its importnat for transparency to have the logs available
15:40:41 <trishnag> bowlofeggs: yeah
15:40:58 <trishnag> dgilmore: +1
15:41:23 <dgilmore> bowlofeggs: at least the mash logs
15:41:28 <dgilmore> and the ostree logs
15:41:32 <dgilmore> if not all the logs
15:41:54 <dgilmore> the mash and ostree logs can help people help us
15:42:09 <bowlofeggs> dgilmore: i still feel on the fence about that one
15:42:18 <bowlofeggs> i can see that argument and i agree that would really be helpful
15:42:35 <bowlofeggs> but i also worry that some dependency of ours may log something that shouldn't be public
15:42:49 <bowlofeggs> a credential, or some other secret
15:42:56 <bowlofeggs> only because i've seen it before multiple times
15:43:11 <bowlofeggs> 3-4x about
15:43:33 <dgilmore> https://github.com/fedora-infra/bodhi/issues/844 should be a hig priority also
15:43:52 <bowlofeggs> you know, some developer sticks a log.debug(my_secret_password) in there while developing, accidentally commits it, and now it's available to the public
15:44:03 <dgilmore> bowlofeggs: when we used mash for rawhide/branched the mash logs were always public
15:44:31 <dgilmore> bowlofeggs: neither mash, now ostree have authentication in them
15:44:47 <dgilmore> I get what you are saying, I strongly disagree with you
15:45:21 <dgilmore> bowlofeggs: we also make all logs from pungi public
15:45:40 <dgilmore> I have commited to having everything releng does be open and transparent
15:45:51 <dgilmore> at the moment bodhi is the only thing that is not
15:45:54 <bowlofeggs> i marked 844 high prio
15:46:32 <bowlofeggs> dgilmore: can you add a comment to the issue about it? i'm willing to go with what releng wants here
15:46:46 <bowlofeggs> dgilmore: are we talking about limiting the logs to just ostree, or all bodhi logs should be visible?
15:47:58 <dgilmore> bowlofeggs: at the least mash and ostree
15:48:15 <dgilmore> bodhi's internal logs I care less about
15:48:19 <bowlofeggs> dgilmore: cool - neither of those particularly worry me, especially since mash shouldn't need a password anymore
15:48:30 <bowlofeggs> dgilmore: let's make it so then
15:48:32 <dgilmore> bowlofeggs: mash has never needed a password
15:48:40 <dgilmore> it does not support auth
15:49:00 <bowlofeggs> oh i thought it used to. but then again, i've never actually run it before since i can't
15:50:26 <bowlofeggs> any other issues? shall we move to open floor?
15:51:21 <bowlofeggs> #topic Open floor
15:51:26 <dgilmore> bowlofeggs: too many issues to go over :(
15:51:37 <bowlofeggs> dgilmore: yeah there really are
15:51:46 <bowlofeggs> i've been trying to go through them a little here and a little there
15:51:48 <bowlofeggs> but there are a lot
15:51:59 <bowlofeggs> i do read and label new ones as they come in now
15:52:01 <bowlofeggs> so that helps
15:52:08 <dgilmore> :)
15:52:15 <bowlofeggs> but there's so many from before i was working on the project that i also need to take care of
15:52:49 <bowlofeggs> to be honest, the number of critical/high prio items is already difficult for me to keep up wtih ☺
15:53:07 <bowlofeggs> but it does help to keep those labels
15:53:45 <bowlofeggs> one thing i still want to work towards that will take some time is getting bodhi mashing to be automatic
15:54:07 <bowlofeggs> now that signing is automatic i think the only thing stopping bodhi from being automatic is its instability
15:54:35 <bowlofeggs> so i want to put some more work into stabilizing the mash, making it retry on network failures, being able to clean up after problems more automatically, etc.
15:54:55 <bowlofeggs> i think it's still far away from that goal, but i do think it's achievable
15:55:14 <dgilmore> I am not sure we should do mashing automatically
15:55:32 <bowlofeggs> dgilmore: what are the downsides to that?
15:55:38 <dgilmore> we generally do not reject updates, but an admin is supposed to make sure that an update is okay
15:55:43 <dgilmore> its the last gatekeeper
15:56:07 <dgilmore> the question also comes up of how often we mash
15:56:27 <dgilmore> as soon as its automated people will want it to happen as soon as an update goes stable
15:56:28 <bowlofeggs> oh, so basically jsut having a human look at the list of packages and typing y/n is what we want to keep?
15:56:33 <dgilmore> but we can not do that
15:56:53 <dgilmore> bowlofeggs: well in theory we may notice something thats not allowed
15:57:02 <bowlofeggs> oh ok yeah
15:57:10 <dgilmore> say someone slips in a banned project
15:57:18 <mboddu> and also not pushing stables during freezes and what releases to be pushed might be difficult
15:57:25 <dgilmore> there is multiple places that can be picked up
15:57:30 <bowlofeggs> dgilmore: well in that case, i still want mash to be *able* to be automatic, even if it never *is* automatic, just because that means it's stable ☺
15:57:43 <mboddu> since freeze times changes if we delay the release compose
15:57:53 <bowlofeggs> yeah that's a good point too
15:58:44 <bowlofeggs> well that's ok, i'm happy to keep it manual and just focus on making it robust
15:58:54 <dgilmore> technically we can only push to mirrors no more than twice a day
15:59:03 <dgilmore> any more often mirrors will not keep up
15:59:10 <dgilmore> even at twice a day they may not keep up
15:59:18 <bowlofeggs> yeah i know the mirrors are a tricky side to it, since we want to limit the churn
15:59:23 <dgilmore> I would like us to only push once a week or once a month
15:59:43 <dgilmore> testing daily but stable much less frequently
15:59:53 <dgilmore> security updates as they happen
16:00:13 <bowlofeggs> yeah that seems to be how downstream tends to handle it more
16:00:27 <bowlofeggs> well is there anything else anyone wants to say? shall i wrap this up?
16:00:51 <bowlofeggs> (also, i apologize again for my tardiness. the repair was badly timed)
16:01:06 <bowlofeggs> 5
16:01:08 <bowlofeggs> 4
16:01:09 <bowlofeggs> 3
16:01:10 <bowlofeggs> 2
16:01:12 <bowlofeggs> 1
16:01:14 <bowlofeggs> #endmeeting