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