14:30:03 #startmeeting Pulp Triage 2020-09-29 14:30:03 #info fao89 has joined triage 14:30:03 !start 14:30:03 Meeting started Tue Sep 29 14:30:03 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:03 The meeting name has been set to 'pulp_triage_2020-09-29' 14:30:03 fao89: fao89 has joined triage 14:30:35 #info daviddavis has joined triage 14:30:35 !here 14:30:35 daviddavis: daviddavis has joined triage 14:30:39 lol 14:30:41 #info ggainey has joined triage 14:30:41 !here 14:30:41 ggainey: ggainey has joined triage 14:30:42 #info ppicka has joined triage 14:30:42 !here 14:30:42 ppicka: ppicka has joined triage 14:30:44 #info GregorSamsa has joined triage 14:30:44 !here 14:30:44 GregorSamsa: GregorSamsa has joined triage 14:31:08 Open floor - https://hackmd.io/@pulp/triage/edit 14:31:30 topic: PoC for automatic PR merges https://github.com/pulp/pulp-ci/pull/737 14:31:41 I am looking for some feedback here 14:32:00 this was partly motivated out of choosing different merge strategies in different situations 14:32:00 #info ipanova has joined triage 14:32:00 !here 14:32:00 ipanova: ipanova has joined triage 14:32:12 #info dkliban has joined triage 14:32:12 !here 14:32:12 dkliban: dkliban has joined triage 14:32:19 but it's a huge change in how PRs are merged 14:32:33 I'm biased to comment daviddavis PRs 14:32:43 lol 14:32:46 hmmm 14:32:47 :D 14:32:58 daviddavis: so is the net here, "if a PR has been reviewed, approved, and can be clean-merged, it automatically gets a rebase-merge immediately"? 14:33:09 ggainey: correct 14:33:15 and is not a draft pr 14:33:19 here's the relevant bits https://git.io/JU1Ml 14:33:47 daviddavis: i am a little hesitant about auto merging 14:33:47 yeah 14:34:00 dkliban: me too 14:34:20 mostly because yesterday i had a PR that was approved but i still ended up making more changes to it 14:34:47 so you can control whether a PR gets auto merged or not as a developer by setting it to draft 14:34:48 #info ttereshc has joined triage 14:34:48 !here 14:34:48 ttereshc: ttereshc has joined triage 14:34:58 gotcha 14:35:21 another project that does this is openshift 14:35:58 I don't think we'll decide today but I just wanted to bring this up for questions and comments 14:36:01 this will require us to really not forget using the draft option 14:36:06 yup 14:36:26 is there way to set github to always start PR as draft? 14:36:45 it would be nice but I don't think so 14:37:38 when we were evaluating the pr processor we have identified that pulpcore and pulp_rpm uses it but i think there were not any other plugins 14:37:53 #info bmbouter has joined triage 14:37:53 !here 14:37:53 bmbouter: bmbouter has joined triage 14:38:02 there are also some PRs which would be good to have multiple approvals and not just one 14:38:17 I could see pulpcore having a 2-ack requirement 14:38:19 here are the repos https://git.io/JvSEi 14:38:52 but the PRs the processor starts were the ones already approved and merged 14:39:03 ttereshc: yea, you could use the draft feature and just set it back to draft if you want to approve it and not merge. or you can leave a comment saying that you approve and ask the next approver to leave an approval which will merge. 14:39:08 or do we have other PRs beyond cherrypick? 14:39:13 ipanova, I think you are thinking about cherry picks, they were not used by many 14:39:16 i would be cool with 2 acks for pulpcore 14:39:37 me too 14:39:42 me too 14:39:52 * ttereshc is joining the party as well 14:39:55 hehe 14:40:35 so I can follow up with an email to pulp-dev to ask for more feedback on automatic merging 14:40:44 I want some time to think about it too 14:40:48 i am cool if having 2 acks 14:41:03 +1 14:41:07 cool, I can set the number of approvals on pulpcore to 2 and we can try that out 14:41:09 ttereshc: correct 14:41:13 I think I misunderstood the PR, I thought it was only for cherrypicks 14:41:14 humans clicking merge buttons are not really helping I don't think 14:41:22 fao89: no, it's all PRs 14:42:12 if they are mergeable (passing CI, required number of acks, no nacks, and not a draft) they get merged 14:42:40 it does require us to be more careful with our acks 14:42:45 so we should discuss it more. 14:42:52 anyway, I'll send out an email on pulp-dev 14:43:03 +1 14:43:08 I would go with automatic merge for cherrypicks first 14:43:40 sure that might be a solution 14:44:05 if that's all its doing though we could just take noa ction 14:44:10 or auto-merge by specific tag 14:44:32 fao89: can you express the concern with auto merging everything? 14:45:12 I just want to break a "huge" change in minor ones 14:45:51 ok 14:45:58 cool, let's continue on pulp-dev. I don't want to monopolize open floor 14:46:14 topic: Do we support backporting fixes that include migrations? 14:46:46 from our sept 4th open floor my understanding is we do not and indeed can not 14:46:50 I added this question. I think eventually we'll get a backport request for a bug fix that involves a migration so I figured it would be better to discuss now instead of in the heat of the moment 14:46:57 ok 14:47:30 daviddavis: from what i remember we decided to postpone this discussions once we have a case 14:47:37 case==request 14:47:39 django migration machinery does not support this 14:47:51 daviddavis: I think if/when that happens, we're going to be stuck doing manual migration-work for whatever we're chjerrypicking into 14:47:53 or at least that is my current understanding of it 14:47:54 yah 14:48:12 this was also my takeaway from that convo 14:48:29 iirc dalley and x9c4 pointed out something specific meaning we never could 14:48:37 so the answer I hear is no we don't support it? 14:48:47 I agree with daviddavis that it's helpful to find a way forward now and not when we get to this point 14:49:11 i don't remember the specifics, can dalley, x9c4 please remind? 14:49:12 +1 14:49:42 ttereshc: i would like to find a way to do it ... however, i don't know how to do it 14:49:43 we don't do backports with migration normally and I think we agreed that we won't support it as a usual workflow but we need a solution for critical cases 14:49:43 I don't think we can do it if they're out of order 14:49:59 if they're in-order, it might be OK 14:50:07 yea I think our migrations are order dependent and cannot be run out of order 14:50:27 yup, i see 14:50:31 so the question is what to do when it's needed 14:50:53 because I believe there will be such situation, downstream 14:50:53 so if master is at 0007 and the branch is at 0005, it would be ok to cherry pick 0006, but not 0007 14:51:00 *probably 14:51:10 downstream is a separate source tree 14:51:25 that gets us back into the painful situation where we have to renumber migrations 14:51:32 and actually per the convo their I was explaining to them that we don't have capacity to do that 14:51:32 I think the discussion we had about this was this PR: https://github.com/pulp/pulpcore/pull/863 14:51:43 daviddavis, renumbering might not help with django migraitons 14:51:44 so either hire someone to do it, or they get upstream migrations and that is all 14:51:53 whether we should cherrypick or not and we decided to not cherrypick 14:52:27 we do not have capacity to manage backports (migrations or otherwise) for downstream is my thesis from yesterday's convo 14:53:29 bmbouter, I think regardless of capacity we need to know how to do out-of-order migrations, without re-writing pieces of code 14:53:43 agree 14:53:52 or to be sure that we can, so we are not stuck when we do have capacity 14:54:04 or not us but whoever deals with it 14:54:24 agreed. capacity aside, I think dalley's point calls out the technical situation well 14:54:40 if the one being released was "the very next migration" then it would be possible 14:54:55 I'm voting to dedicate some time to investigate flexibility of django migraitons if it hasn't been done 14:55:13 we know it is not possible already 14:55:24 django has a "multiple leaf nodes" error 14:55:52 There is a notion of "fake" migration I think if some needs to be skipped. I wonder what else is there. 14:56:07 Ah if someone already did the investigaiton, then ok 14:56:34 I think we should just ask in #djang 14:56:41 #django. if we haven't already 14:56:52 daviddavis: dkliban you've both experienced this error also can you share 14:56:53 i don't think we have talked to folks there about this 14:57:24 I guess I see this info as already understood 14:57:27 I did hit this error but didn't really look into it. I can take an AI to research further 14:57:56 ie I didn't try to work around it 14:58:05 I think we'd probably get a conclusive answer in about 5 minutes if we bring it up in the channel :) 14:58:06 i've only read a lot of docs about this. i have not experimented with any strategies for working around the problem 14:58:13 dalley: i agree 14:58:15 i think it would valuable to look into this more so then we can close this chapter and say whether it is possible or not. 14:58:26 dalley: agree 14:58:32 that's fine with me, but I guess I feel like I'm saying it isn't but folks aren't hearing that 14:58:54 bmbouter: i think folks mostly wants to see the proofs :-P 14:59:25 that's fair, let's get the proofs 14:59:28 bmbouter, I understand, I've run into the error too, and I'm not really that optimistic. I just think it's worthwhile to ask 14:59:37 we shouldn't spend more time on this though IMO 15:00:02 +1, who is going to ask in #django? 15:00:17 agreed, ran into issue, not optimistic, but downstream would need a way out eventually, +1 to ask in #django 15:00:29 I can ask 15:00:55 downstream would hire more people to maintain their source tree or accept the upstream migrations 15:00:57 thank you daviddavis 15:01:27 topic: FYI: 3.7.1 is releasing today with 1 packaging fix 15:01:30 it's frustrating my analysis is not convincing 15:01:31 bmbouter: that would be ideal solution, unfortunately not immediate 15:02:04 ipanova: no they said they won't hire folks so that means they are choosing to accept the upstream migrations 15:02:25 bmbouter: i see, i did not have that piece of info 15:02:47 bmbouter, I guess I don't see the solution, whether they hire people or not, just from technical point of view. 15:03:10 downstream would renumber all migrations with every upgrade similar to what is done with pulp2 15:03:17 if they had the folks to do it 15:03:30 bmbouter, I think renumbering doesn't work for django case 15:03:36 that's my concern 15:03:48 it would they all get renumbered to be linear 15:04:01 this avoids the "multiple leaf node" graph issue django refuses to migrate with 15:04:16 basically all the migrations need to be linearly applied 15:04:22 you mean change the dependency for each migration? 15:04:29 yeah exactly 15:04:33 what if the current release is 002 and then you need to backport 003? 15:04:53 I think this goes back to dalley's example 15:05:01 which hits the nail on the head 15:05:12 so renumbering doesn't solve the problem? 15:05:42 if we're saying we can renumber (downstream only) then they swap 0002/0003 15:05:51 like let's say 6.11 is out in the wild with 002 and we need to backport 003 to 6.10.1 15:05:59 if downstream already released 0002 then you can't put a new one ahead of it 15:06:03 and 6.10 has 001 15:06:36 I see so renumbering doesn't solve the problem 15:06:49 renumbering will not solve that problem 15:07:05 please, please don't change the contents of migrations 15:07:18 renumbering will solve the "I want a selective number of upstream migraitons" applied just for this release 15:07:25 folks, there are a TON of edge-cases here 15:07:26 dalley: I agree completely 15:07:42 hey, so I'm not sure the "number" is really that important 15:07:53 I'm pretty sure they use the entire name of the migration 15:07:58 ggainey: I agree this is why my thesis from yesterday is downstream would need to hire people or accept the upstream migrations as-is 15:08:00 the number just keeps them in order 15:08:04 and if they opt not to hire, that is their choice 15:08:07 dalley: agreed 15:08:12 (and we haven't even talked about what happens when you want to upgrade from a backported-old-version to a new(est) version) 15:08:16 we have 3 issues for triage 15:08:43 bmbouter: I agree, honestly - "if you want to cherry-pick a fix that includes a migration, you get *all* the migrations" 15:09:02 do we want to keep this migration discussion or move to triage? 15:09:35 so the main motivator is to "solve this for downstream" and what I'm saying is that's not a thing 15:09:49 my take is "1) we say No :)", and "2) if it needs more nuance than that, it needs a more-organized discussion than ad-hoc IRC" 15:10:33 I'm going to look more into whether it's technically possible. seems like in #django they say we can manually check dependencies ourselves 15:11:16 daviddavis: sounds good 15:11:22 +1 15:11:40 #info x9c4 has joined triage 15:11:40 !here 15:11:40 x9c4: x9c4 has joined triage 15:11:50 works for me 15:11:53 if it's not technically possible, I'll update our docs to say we can't backport migrations and explain the technical problem 15:12:08 sounds like a plan 15:12:14 daviddavis: thank you 15:12:17 +1 15:12:43 triage time! 15:12:47 !next 15:12:48 fao89: 3 issues left to triage: 7617, 7609, 7548 15:12:49 #topic https://pulp.plan.io/issues/7617 15:12:49 RM 7617 - evgeni - NEW - pulpcore-selinux version disagrees with tag 15:12:50 https://pulp.plan.io/issues/7617 15:13:14 #idea Proposed for #7617: Leave the issue as-is, accepting its current state. 15:13:14 !propose accept 15:13:14 fao89: Proposed for #7617: Leave the issue as-is, accepting its current state. 15:13:26 it is already on the sprint 15:13:27 +1 15:13:30 +1 15:13:32 it is already on the sprint 15:13:33 +1 15:13:35 yep 15:13:37 #agreed Leave the issue as-is, accepting its current state. 15:13:37 !accept 15:13:37 fao89: Current proposal accepted: Leave the issue as-is, accepting its current state. 15:13:38 #topic https://pulp.plan.io/issues/7609 15:13:38 fao89: 2 issues left to triage: 7609, 7548 15:13:39 RM 7609 - mdepaulo@redhat.com - NEW - pulpcore-selinux's Makefile is incomplete and unused 15:13:40 https://pulp.plan.io/issues/7609 15:14:08 accept and add to sprint 15:14:12 +1 15:14:26 #idea Proposed for #7609: accept and add to sprint 15:14:26 !propose other accept and add to sprint 15:14:26 fao89: Proposed for #7609: accept and add to sprint 15:14:35 #agreed accept and add to sprint 15:14:35 !accept 15:14:35 fao89: Current proposal accepted: accept and add to sprint 15:14:36 #topic https://pulp.plan.io/issues/7548 15:14:36 fao89: 1 issues left to triage: 7548 15:14:37 RM 7548 - dalley - NEW - "commit check" should allow references to issues that are outside of the project 15:14:38 https://pulp.plan.io/issues/7548 15:15:17 we skipped this one last time 15:15:32 have we learned anything new since then or do we need to skip again/ 15:15:34 ? 15:15:56 I think it needs some discussion either here or on the issue 15:16:26 Is "references" like "re #1234" only? 15:16:34 i think so 15:16:39 dalley: is taht right? 15:16:42 or does it include "fixes #1234" 15:16:59 my understanding is that it's just "ref" and "re" 15:17:06 just ref and re 15:17:34 I think it is a matter of defining another term for replacing ref or re 15:17:39 So the ticket will be move to the project it is finally solved, but other repos can prepare the solution. 15:17:49 so for instance I had that issue recently that required a fix in both pulpcore and pulp_rpm separately 15:17:54 cc #9999 would not match the regex 15:18:18 it's the same exact issue, it just hit pulp_rpm specifically because they duplicate some code from pulpcore 15:18:30 i think i prefer having a separate issue in pulpcore 15:18:43 well, it was a pulpcore issue 15:18:54 i mean issue per repo 15:19:02 s/repo/project 15:19:09 that was my suggesiton to file an issue for each change but I can see that might be annoying for some people 15:19:44 daviddavis: yeah 15:19:47 it is an extra step - but having been here myself recently, I just cloned the issue I was working on and moved the clone to the new project 15:20:02 the alternative were "[noissue] Copied solution from pulpcore commit asdf"? 15:20:20 which is basically what I did ^ 15:20:52 yeah 15:21:26 I personally think that filing an issue is better for bookkeeping also forces us to think about things like whether a change needs a changelog 15:21:32 benefit of the cloned issue is that you get a changelog entry 15:21:52 and an issue that can be associated with a milestone in redmine 15:21:56 daviddavis: you were faster 15:21:59 hehe 15:22:08 yeah 15:22:08 let's say that in the future we make a plugin API breaking change, we then need to either make an issue for every plugin, or forgo the automation 15:22:16 yes 15:22:31 even if there's no user-visible change 15:22:45 but it *is* user-visible - plugin authors are users too :) 15:23:04 I'm talking about the changelogs for the plugins themselves 15:23:19 it makes sense to be in the plugin API changelog of course 15:23:20 not in the future, in the past: https://pulp.plan.io/issues/6888 15:23:59 s/not in/not only in 15:24:27 I am personally more concerned about the use case where a developer makes a user visible change against a plugin, uses ref, and then doesn't create a changelog entry 15:24:49 that seems to outweigh the extra time it takes to file issues against plugins 15:24:51 for me at least 15:25:20 i prefer being padentic and filing more issues 15:25:28 yeah same 15:25:37 pedantic* 15:25:46 heh 15:25:48 ok. close - wontfix, then? 15:25:49 thank you 15:25:51 lol 15:25:55 i have almost seen "pandemic" 15:25:55 dalley: i think so 15:26:01 LOL 15:26:04 dalley: yeah, I think so 15:26:16 ipanova: *everything* is pandemic right now :) 15:26:21 #idea Proposed for #7548: close wontfix 15:26:21 !propose other close wontfix 15:26:21 fao89: Proposed for #7548: close wontfix 15:26:25 #agreed close wontfix 15:26:25 !accept 15:26:25 fao89: Current proposal accepted: close wontfix 15:26:26 fao89: No issues to triage. 15:26:43 i think it is also easier to document and explain that you need an issue per each change then explaining the corner case daviddavis outlined 15:27:39 end? 15:27:48 end-ish? 15:27:50 #endmeeting 15:27:50 !end