15:01:24 #startmeeting Bodhi stakeholders (2017-07-18) 15:01:24 Meeting started Tue Jul 18 15:01:24 2017 UTC. The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:24 The meeting name has been set to 'bodhi_stakeholders_(2017-07-18)' 15:01:25 #meetingname bodhi_stakeholders 15:01:25 The meeting name has been set to 'bodhi_stakeholders' 15:01:27 #topic salutations 15:01:28 #chair acarter bowlofeggs caleigh dgilmore masta mboddu nirik pbrobinson puiterwijk trishnag Kellin 15:01:28 Current chairs: Kellin acarter bowlofeggs caleigh dgilmore masta mboddu nirik pbrobinson puiterwijk trishnag 15:01:29 .hello dustymabe 15:01:30 dustymabe: dustymabe 'Dusty Mabe' 15:01:47 o/ 15:01:50 * nirik is here, but a bit groggy 15:01:50 .hello trishnag 15:01:51 trishnag: trishnag 'Trishna Guha' 15:04:20 * masta_ lurks 15:04:36 .hello ryanlerch 15:04:37 ryanlerch: ryanlerch 'Ryan Lerch' 15:05:04 there's not a ton on the agenda today 15:05:15 #topic announcements and information 15:05:16 #info A Bodhi 2.9.0 beta is deployed to stg: https://bodhi.stg.fedoraproject.org/ 15:05:18 #info Release notes available at https://bodhi.stg.fedoraproject.org/docs/release_notes.html 15:05:49 2.9 is mostly a bugfix release, but there's some features too 15:05:54 lots of CLI stuff 15:05:56 bowlofeggs: +1 15:06:01 .hello jcline 15:06:02 jcline: jcline 'Jeremy Cline' 15:06:42 it's got some preliminary patches from caleigh that will help bodhi support "batched updates" 15:06:59 that's an exciting feature i think - it was discussed on devel@ 6ish months ago 15:07:35 the idea is that bodhi will automatically batch "non-high severity" updates (meaning, non-security and non-urgent) into a weekly push instead of pushing all stable updates every day 15:07:58 this is one of those rare bodhi features that will make a difference to end users, which is cool 15:08:07 hopefully this will reduce the daily churn of fedora 15:08:09 weekly updates? 15:08:19 and end users should only see updates that are severe 15:08:30 masta_: that would be a matter of releng policy, but i would suggest weekly 15:08:59 so it's just a capability we have, right? we can batch things for later pushes? 15:09:00 masta_: basically, there will be a cron script that will run on $schedule that will switch the batched updates to stable 15:09:21 and schedule can be decided by releng, but i think weekly is probably a good recommendation 15:10:01 interesting feature, cool 15:10:02 masta_: all non-urgent updates will automatically go into request: batched instead of request: stable. when the cron job runs, it just switched the request: batched to request: stable 15:10:16 nice and simple approach, and pacakgers will be able to override too 15:10:36 security updates and high severity updates will still go straight to stable like they do today 15:10:51 bowlofeggs: is there any feedback in the UI for when an update is "staged"? 15:11:01 anyways, this won't actually be in 2.9.0 - 2.9.0 just has some of the database work needed to make it happen - it'll be in a later release 15:11:10 just wanted to highlight that progress has been made ☺ 15:11:31 bowlofeggs, does this open the way for highly urgent fixes having a fast path ? 15:11:55 ryanlerch: the plan is to have the UI say "batched" instead of "stable" on the request. hopefully with a tooltip to explain what it means 15:12:14 bowlofeggs: coolio! 15:12:35 masta_: i would think probably so in the sense that i think the daily mashes should go faster since there should be fewer updates in them. i'm not certain though 15:12:49 rel-eng has an old issue/ticket for that, and we never conceived a great way to move forward urgent CVE's outside the normal push work flow 15:12:56 i'm not confident how much the number of updates affects the time to mash 15:13:03 bowlofeggs: does this mean we could not create drpms daily 15:13:13 i'd expect it to help some, but i'm not sure it's linear (i'd guess it probably isn't linear) 15:13:20 but only when a new rpm makes it into batched? 15:13:51 dustymabe: the drpms would be created when the updates gets mashed, so most updates would only be done on the schedule (weekly, for example) 15:14:49 k 15:14:49 I suspect it makes very little speed difference if it's 1 update or 10. 15:14:53 masta_: it is currently possible to push a specific set of builds, which i think could be used to push an urgent cve 15:15:07 masta_: bodhi-push --help talks about a --builds flag 15:15:53 nirik: yeah it might not - the mashing time is probably just due to making the repo data and the repo isn't getting smaller 15:16:05 nirik: but the drpm generation bit should go faster at least 15:16:11 so there should be some difference 15:16:22 i'm not sure how much difference it would be 15:16:28 the feature is more about end users than it is about mash time 15:16:48 bowlofeggs: nirik: just out of interest, what is the mash time at the moment? 15:16:49 the goal is to reduce how often your computer tells you it wants to install 79 updates ☺ 15:16:51 ballpark 15:17:01 ryanlerch: i'd throw out 8-12 hours? 15:17:10 bowlofeggs: so part of what my thoughts are on the weekly bathed updates are that there is a batched update but also another stream people can follow 15:17:13 that's to mash everything 15:17:27 that represents what is pending the next batch 15:17:31 I think it's less than that, but I haven't looked recently 15:17:44 yeah i haven't actually timed it either 15:17:46 just a guess 15:18:14 dustymabe: that could be cool, though that would be yet another repo to mash and mirror (unless we didn't think it needs to be mirrored) 15:18:19 dustymabe: we already have updates-testing 15:18:23 whcih isn't exactly the same 15:18:25 but kinda similar 15:18:33 bowlofeggs: what happens with rawhide today? 15:18:45 don't those rpms get put into the repos faster ? 15:18:55 dustymabe: i don't know much about how rawhide works 15:18:59 once a day... 15:19:02 yeah the rawhide repo seems to be daily 15:19:11 bodhi doesn't make rawhide 15:19:21 nirik: what creates the repo for rawhide? is that the nightly pungi run? 15:19:22 and it takes about 8 hours... because it also makes all the images and such 15:19:31 (though i like the suggestion of making a "bikeshed" distro with rawhide + bodhi) 15:19:32 yes, cron job that runs pungi 15:20:28 anyways, i'm excited about the feature and caleigh is doing good work ☺ 15:20:42 hard to say if it'll be in 2.10 or not, but it could be! 15:20:47 i do think it'll be in 2.11 at least 15:20:56 so ~next 1-2 months 15:21:25 we are going to give developers the ability to override and go straight to stable, so i'm also hoping to be able to gather statistics on how often they choose to do that 15:21:30 because we'd like them to generally not do that 15:21:46 but i also don't want to force a policy on them 15:22:05 so the plan is to monitor and see how much people do it and react if it seems like it's done too much 15:22:14 "react" might mean just writing a plea e-mail ☺ 15:22:46 or possibly making the UI ask nicely not to do that unless it's truly importnat, and if it's important why isn't it marked severe? ☺ 15:23:10 hum? 15:23:19 direct to stable with no karma? 15:23:21 what's the point in enabling them to go straight to stable? 15:23:38 thats against updates policy. ;) 15:24:58 nirik: sorry - what i mean is skipping the "batched" state 15:25:08 users can't go to batched until they meet the stable requirements 15:25:25 ah, I see... 15:25:29 but if they are in batched, we will allow them to click a button to go to stable to skip the batching 15:25:42 yeah, that makes sense. ;) 15:25:44 and i want to monitor it because i'm worried that too many people will do that 15:25:47 i see - so basically the ability to skip batched 15:25:50 cool +1 15:25:50 yes 15:25:57 you should provide a 'comment box' 15:26:01 for them to say why they are doing it 15:26:09 and we can look at those reasons over time 15:26:24 i want to give the freedom to do that, but i want to also see if it's happening so much that the feature isn't helping the users 15:26:31 yeah 15:26:35 btw I have to run - just wanted to say if possible let's get stg in order so we can run bodhi there and test the pungi repo creation with bodhi 15:26:40 i think at first i'll just watch for how much it happens 15:26:44 and go from there 15:26:46 (not including mash, which I know doesn't work in stg) 15:26:52 anyways, let's move on 15:26:54 ok I have to run 15:26:56 bye all 15:27:31 dustymabe: i still can't do taht today - i need to fix a bug for kevin still regarding alternate arches and mash configs 15:27:48 dustymabe: i spent way too much time trying to get staging working yesterday and haven't gotten to that unfortunately 15:28:05 #topic Looking forward 15:28:06 #info Bodhi's high priority issue list https://github.com/fedora-infra/bodhi/issues?q=is%3Aopen+is%3Aissue+label%3A%22High+priority%22 15:28:08 #info High priority means it's important, but not a show stopper 15:28:09 Any filed issues that aren't on these lists that should be? 15:30:37 15:31:23 * nirik doesn't think so 15:31:56 cool 15:32:07 #topic Open floor 15:39:53 ok, let's call it 15:39:57 thanks for coming everyone! 15:40:04 #endmeeting