14:32:51 <mboddu> #startmeeting RELENG (2017-05-22)
14:32:51 <zodbot> Meeting started Mon May 22 14:32:51 2017 UTC.  The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:32:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:32:51 <zodbot> The meeting name has been set to 'releng_(2017-05-22)'
14:32:51 <mboddu> #meetingname releng
14:32:52 <zodbot> The meeting name has been set to 'releng'
14:32:52 <mboddu> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
14:32:52 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
14:32:52 <mboddu> #topic init process
14:33:17 * masta is here
14:33:21 * sharkcz is here
14:34:22 <Kellin> .hello kellin
14:34:23 <zodbot> Kellin: kellin 'None' <kellin@retromud.org>
14:34:54 <mboddu> Dennis is swamped with meetings, based on how many people will show up, we might cancel this meeting
14:34:59 <nirik> morning
14:35:45 <mboddu> Oh, I think we got enough, lets start
14:36:11 <mboddu> #topic #6756 "ActionNotAllowed" when attempting "koji untag-build f27"
14:36:18 <mboddu> #link https://pagure.io/releng/issue/6756
14:37:32 <nirik> currently I don't think theres any way to re-add that ability. We could down the road by adding more tags...
14:37:47 <mboddu> So, this is because of autosigning and is there a way that we can provide untagging of builds to the maintainers?
14:38:04 <mboddu> nirik: what do you mean by more tags?
14:38:42 <nirik> have autosign tag into f27-compose-pending or something that allows people to untag from it, then have compose scripts when they run move anything in that tag to f27
14:40:22 <masta> makes sense to me
14:40:24 <mboddu> so, something like staging for builds until the compose process starts. I think that is the best way to do it
14:40:47 <nirik> yeah, but it's not going to be somethng we do overnight. :)
14:41:33 <mboddu> yes, definitely, so what are all the tool changes that we need? robosignatory and fedpkg and anything else?
14:42:42 <nirik> probibly those two
14:44:21 <mboddu> Okay, I will add that to the ticket
14:46:12 <mboddu> #info The best way to handle this issue is by adding a staging tag from which users can untag their builds and during the compose process tag them into f27 and perform normal compose
14:47:16 <mboddu> #topic #5886 need method for distributing urgent fixes... urgently
14:47:22 <mboddu> #link https://pagure.io/releng/issue/5886
14:47:51 <mboddu> Last time when we talked about this ticket, we decided to check if anyone still wants it or not. Seems like people still want it
14:48:21 <mboddu> So, how can we handle this?
14:49:23 <mboddu> But my guess is that whatever the solution is, it might need a lot of changes to Bodhi and other tools
14:49:54 <nirik> I still think the way forward is to improve our existing tools/flow... no one has cycles to try and do weird special cases
14:52:26 <nirik> I can make a comment to that effect, but not sure what we can otherwise decide on it today
14:53:13 <mboddu> nirik: https://pagure.io/releng/issue/6617 this might help(not cron but some other way to handle that) and something in there to do pushing of updates if they are marked as security fix
14:53:34 <nirik> well, perhaps.
14:53:54 <nirik> I thought of another issue with too fast updates the other day: locking.
14:54:44 <nirik> user submits update, it gets pushed to testing. Someone karmas it up and it gets submitted for stable. Stable push happens and it's locked. If the maintainer wanted to revoke it for any reason the window to do so is... very small.
14:55:39 <mboddu> Haha, both fast and slow are problems for us
14:55:53 <nirik> yeah, there's no magic answer I fear.
14:56:18 <puiterwijk> nirik: well, if we get the updates repos to build very fast, we can just allow hitting the revoke button, and if that happens to any update in the mash, we just throw out the mash?
14:56:44 <puiterwijk> Sure, that'll result in some wasted mashes, but if they're quick that doesn't matter too much
14:56:48 <nirik> sure, but thats quite the waste of cpu/disk/etc
14:56:55 <puiterwijk> Yep
14:57:17 <puiterwijk> But how often does it happen that someone revokes it while it's on its way to a repo?
14:57:36 <puiterwijk> (or that they'd want to)
14:57:48 <nirik> Dunno.
14:58:02 * nirik thinks this is a discussion for flock... there's lots of parts.
14:58:04 <puiterwijk> If it happens once a week, I'd be "meh, it's fine". If it's once a day, I'd agree it's a waste
14:59:10 <mboddu> I agree with puiterwijk but we need to discuss more about it, and probably as nirik mentioned, flock might be a good place to talk about it
15:00:14 <nirik> triggering mashes on security is something we could do... but not sure everyone would be happy
15:04:34 <mboddu> #info First, we should try to improve our existing tools/flow. Second, fast moving updates might also create issues if the maintainer decides to revoke the update since the time window will be very small. So, we plan on discussing more about it during flock.
15:05:18 <mboddu> Okay moving on
15:05:28 <mboddu> #topic #6365 "Broken dependencies" report does not understand rich dependencies
15:05:34 <mboddu> #link https://pagure.io/releng/issue/6365
15:07:13 <nirik> That script needs porting to dnf most likely
15:07:32 <mboddu> nirik: I think it needs more than that
15:07:36 <nirik> also, people shouldnt be using rich deps since we cannot ever push updates for them. ;)
15:07:43 <nirik> (well, some kinds of)
15:08:18 <mboddu> nirik: porting to dnf is the first step to support rich and weak dependencies
15:08:58 <mboddu> nirik: is there a road map to support rich/weak dependencies, by what fedora release?
15:09:43 <nirik> no idea.
15:10:30 <nirik> note that the package in question removed it's rich deps
15:10:59 <mboddu> nirik: but I think it will be pretty soon, since we are going full dnf in f27, we can start looking at supporting rich and weak dependencies after that.
15:11:12 <nirik> sure.
15:11:31 <nirik> the broken deps script needs porting to dnf, and mash needs replacing or porting.
15:12:10 <mboddu> nirik: where is the script located?
15:12:28 <nirik> it's in the mash package
15:12:44 <nirik> /usr/share/mash/spam-o-matic
15:13:24 <mboddu> nirik: okay, thanks
15:14:23 <mboddu> #info The broken deps script needs porting to dnf, and mash needs replacing or porting. Also, we can look at supporting rich/weak dependencies after Fedora 27 release which will have dnf support.
15:16:26 <mboddu> #topic #6775 Please Review Arbitrary Branching Change Proposal and Provide Feedback
15:16:32 <mboddu> #link https://pagure.io/releng/issue/6775
15:17:50 <dgilmore> sorry here now
15:18:12 <mboddu> dgilmore: right time when I need you :)
15:18:24 <dgilmore> As I stated in the FESCo meeting, I am okay with arbitory branching but very concerned about the removal in a month of pkgdb
15:20:56 <mboddu> dgilmore: Cant we support both pkgdb and their new system. Like, for modularity use the new system and for good old rpms use pkgdb and we can slowly move towards the new system based on the feedback?
15:21:36 <nirik> no
15:22:09 <nirik> at least thats my understanding
15:23:16 <dgilmore> mboddu: I think we should be able to. but the guys working on it claim otherwise
15:23:30 <dgilmore> I still do not quite understand why that is
15:24:17 <dgilmore> the tricky bit that they claim is the acl generation
15:24:46 <dgilmore> we will still need f27 and f28 etc branches for awhile as well
15:25:17 <dgilmore> I think we will also need to work with threebean and co to sort out where fedpkg fits into the future
15:25:59 <mboddu> dgilmore: hmmm. Do you know if their new system is available in staging for testing purposes?
15:26:22 <dgilmore> mboddu: it is not
15:26:33 <dgilmore> I think they plan to have it in stg this week
15:27:27 <mboddu> dgilmore: that gives 3 weeks or so for testing and move that to prod and remove pkgdb?
15:28:02 <puiterwijk> During a time that a lot of the team is working on the f26 release
15:28:06 <mboddu> dgilmore: that is very small window for testing a new system and removing a working system
15:28:45 <mboddu> puiterwijk: yep, that is true as well
15:29:17 <dgilmore> its a really really tight window
15:29:29 <dgilmore> I know some of the data is supposed to move to pdc
15:29:31 <puiterwijk> I would strongly suggest to push back on anything changing within a month for prod.
15:29:42 <dgilmore> but I do not know how thats supposed to happen
15:29:53 <dgilmore> puiterwijk: indeed
15:30:05 <dgilmore> you can create arbitory branches today
15:30:06 <puiterwijk> I would suggest that if they want this live at the start of a release, they have f28 to do that
15:30:28 <dgilmore> the things that may be missing is visibility in tools and acls may not be 100% what is wanted
15:30:40 <puiterwijk> Since if we still need to test stuff at this point, it's just to late for the start of f27 cycle, in my opinion
15:30:59 <dgilmore> puiterwijk: I agree
15:31:25 <mboddu> puiterwijk: +1
15:32:00 * nirik also thinks it''s tight... but we are just talking amoungst ourselves if no one from the folks doing that is here.
15:32:36 <puiterwijk> Want me to ask them to join?
15:32:40 <dgilmore> #action dgilmore to update the issue and say that we are okay with arbitory branching but concerned over the remove of pkgdb with such little time and insight and will suggest that it should be targets for just after f27 has been branched. and potentially only done for f28 on
15:32:55 <dgilmore> nirik: indeed
15:33:00 <dgilmore> we need to engage them
15:33:00 <puiterwijk> Or that, works too
15:33:17 <dgilmore> the meeting time is up now
15:33:27 <puiterwijk> Ah, okay
15:33:28 <mboddu> puiterwijk: we already went aboard the scheduled time
15:33:52 <puiterwijk> mboddu: I see. I am used to seeing meetings end at the hour so was confused :)
15:33:54 * mboddu thinks if it can be taken to FESCo
15:34:07 <nirik> it has be/was/is...
15:34:07 <dgilmore> puiterwijk: this one starts at the half hour
15:34:15 <nirik> it was discussed a bunch at the last meeting
15:34:19 <dgilmore> I can not remeber why exactly now
15:34:19 <puiterwijk> dgilmore: yeah, I rememberd that now
15:35:13 <dgilmore> mboddu: there is a step in the change process to get releng to review and sign off on all changes
15:35:22 <dgilmore> either to confirm there is nothing we have to do
15:35:33 <mboddu> dgilmore: cool
15:35:39 <dgilmore> or agreee with it or provide feedback and guidance early in the process
15:35:54 <mboddu> Anyway, lets do quick open floor
15:36:02 <mboddu> #topic Open Floor
15:36:22 <mboddu> If anybody got anything?
15:36:33 <nirik> Just a quick heads up on a ticket I will be filing today hopefully:
15:37:04 <nirik> Splitting fedora_koji volume into 2 volumes... moving all the non active stuff to one and leaving the active bits on the current one
15:37:23 <nirik> hopefully we can do that without too much disruption.
15:37:53 <mboddu> nirik: when are you planning to do it, today?
15:38:09 <nirik> we may also want to split out archive from fedora_ftp as well.
15:38:18 <nirik> yeah, I will get it filed today.
15:38:31 <mboddu> nirik: okay
15:38:31 <nirik> more details in the ticket...we can discuss more out of meeting or next week
15:39:25 <mboddu> #info nirik is filing a ticket today to split fedora_koji volume into 2 volumes... moving all the non active stuff to one and leaving the active bits on the current one. We may also want to split out archive from fedora_ftp as well.
15:39:39 <mboddu> Anybody got anything else?
15:40:15 <mboddu> Okay, lets wrap up
15:40:24 <mboddu> Thanks guys for joining
15:40:28 <mboddu> #endmeeting