15:30:12 <daviddavis> #startmeeting Pulp Triage 2020-02-25
15:30:12 <daviddavis> !start
15:30:12 <pulpbot> Meeting started Tue Feb 25 15:30:12 2020 UTC.  The chair is daviddavis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:12 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:30:12 <pulpbot> The meeting name has been set to 'pulp_triage_2020-02-25'
15:30:12 <daviddavis> #info daviddavis has joined triage
15:30:12 <pulpbot> daviddavis: daviddavis has joined triage
15:31:19 <ttereshc> #info ttereshc has joined triage
15:31:19 <ttereshc> !here
15:31:19 <pulpbot> ttereshc: ttereshc has joined triage
15:31:20 <ppicka> #info ppicka has joined triage
15:31:20 <ppicka> !here
15:31:20 <pulpbot> ppicka: ppicka has joined triage
15:31:39 <daviddavis> I guess 3 is enough
15:31:43 <daviddavis> !next
15:31:44 <pulpbot> daviddavis: 2 issues left to triage: 6221, 6217
15:31:45 <daviddavis> #topic https://pulp.plan.io/issues/6221
15:31:45 <pulpbot> RM 6221 - CodeHeeler - NEW - Bindings Issues at Install, Undocumented Fix
15:31:46 <pulpbot> https://pulp.plan.io/issues/6221
15:31:57 <bmbouter> !here
15:31:58 <bmbouter> #info bmbouter has joined triage
15:31:59 <pulpbot> bmbouter: bmbouter has joined triage
15:32:21 <ggainey> #info ggainey has joined triage
15:32:21 <ggainey> !here
15:32:21 <pulpbot> ggainey: ggainey has joined triage
15:32:23 <daviddavis> shouldn't the dev env be building the bindings and not installing htem from pypi?
15:32:52 <ttereshc> +1 to that, I think it's kinda mentioned in the last part of the tickety
15:33:13 <dalley> #info dalley has joined triage
15:33:13 <dalley> !here
15:33:13 <pulpbot> dalley: dalley has joined triage
15:33:27 <ppicka> +1 for check/fix dev env to do that (build)
15:33:36 <dkliban> i thought it was already doing that
15:33:36 <bmbouter> you can't mix pre-release installs w/ released bindings tho
15:34:06 <daviddavis> bmbouter: agreed.
15:34:11 <bmbouter> I don't thikn the solution is to "Solution was to uninstall the old bindings, then pip install from PyPI again using --pre flag." but instead to build them from source
15:34:25 <bmbouter> because those bindings with --pre would also be out of date
15:34:44 <daviddavis> yea so the dev environment bindings should be built and not pip installed
15:34:53 <dkliban> yeah
15:34:56 <daviddavis> I'll follow up on the issue.
15:35:05 <ttereshc> dkliban should remember :) I thought bindings showed version 0.0.0, which meant that they were generated
15:35:30 <ttereshc> dkliban, do you remember why they were not regenrated but installed form pypi?
15:35:31 <dkliban> ttereshc: yeah .. but i think that she needed to reinstallthem but pip was not doing it
15:35:44 <bmbouter> dev environments are build with pbindings
15:35:49 <daviddavis> yea
15:36:02 <daviddavis> I'll ask how she ended up with bindings from pypi
15:36:12 <dkliban> ttereshc: dawalker said that she later noticed that pip was saying that the requirement was already satisfied
15:36:15 <daviddavis> and suggest we document how to generate bindings in dev with pbindings
15:36:26 <ttereshc> +1
15:36:38 <ggainey> +1
15:36:41 <daviddavis> #idea Proposed for #6221: daviddavis to follow up
15:36:41 <daviddavis> !propose other daviddavis to follow up
15:36:41 <pulpbot> daviddavis: Proposed for #6221: daviddavis to follow up
15:36:52 <dalley> I hate those kinds of issues
15:36:54 <dkliban> i gotta go
15:37:05 <ttereshc> o/
15:37:12 <daviddavis> me too. our dependencies can be messy
15:37:17 <daviddavis> bye dkliban
15:37:19 <daviddavis> #agreed daviddavis to follow up
15:37:19 <daviddavis> !accept
15:37:19 <pulpbot> daviddavis: Current proposal accepted: daviddavis to follow up
15:37:20 <pulpbot> daviddavis: 1 issues left to triage: 6217
15:37:20 <daviddavis> #topic https://pulp.plan.io/issues/6217
15:37:21 <pulpbot> RM 6217 - ipanova@redhat.com - NEW - First repo_version can contain duplicates
15:37:22 <pulpbot> https://pulp.plan.io/issues/6217
15:37:32 <bmbouter> daviddavis: I think the real issue is that phelp is broken
15:37:32 <dalley> I once spent more than 2 hours wondering why my changes weren't influencing anything only to find out that pulpcore had been swapped out behind my back
15:37:47 <bmbouter> motd says to use it but it's broken
15:38:11 <bmbouter> for 6217 I think gmbnomis also reported this a while earlier
15:39:03 <ttereshc> +1 to accept it, whether this one or the earlier version of the issue if we have it
15:39:14 <ggainey> accept-and-add?
15:39:19 <daviddavis> bmbouter: weird, it seems to work for me. any chance you file an issue
15:39:29 <daviddavis> ggainey: +1
15:40:37 <daviddavis> #idea Proposed for #6217: accept and add to sprint
15:40:37 <daviddavis> !propose other accept and add to sprint
15:40:37 <pulpbot> daviddavis: Proposed for #6217: accept and add to sprint
15:40:44 <ttereshc> +1
15:40:56 <ppicka> +1
15:41:27 <daviddavis> #agreed accept and add to sprint
15:41:27 <daviddavis> !accept
15:41:27 <pulpbot> daviddavis: Current proposal accepted: accept and add to sprint
15:41:29 <pulpbot> daviddavis: No issues to triage.
15:41:31 <daviddavis> open floor
15:42:02 <ttereshc> https://pulp.plan.io/issues/6222
15:42:41 <bmbouter> nice file
15:42:46 <ttereshc> I filed it today, I wonder if it's easy/possible to fix that, and what others think about it
15:42:50 <daviddavis> I agree with this issue. is this possible in plan.io?
15:42:55 <daviddavis> ha
15:42:58 <ttereshc> :)
15:43:10 <bmbouter> I currently use a behavioral solution
15:43:18 <bmbouter> not a great solution (full disclosure)
15:43:37 <bmbouter> I use re #1234 when I know more work comes later (like from another repo for example)
15:43:48 <bmbouter> and then I use closes # on the last one
15:44:00 <bmbouter> this doesn't handle the case when the last one isn't the actual last one ;)
15:44:12 <bmbouter> but no automation can fix that given that humans themselves believed it was the last one
15:44:20 <daviddavis> I don't see a setting to limit git branches in plan.io
15:44:51 <bmbouter> the issue talks about master but I don't think that's really it
15:45:01 <bmbouter> it meaning the core problem
15:45:46 <bmbouter> the core problem to me is that work is at MODIFIED and then receives additonal commits
15:46:50 <daviddavis> bmbouter: so like I just commited a fix for a subtask to a non-master branch and it closed the issue. there's no more commits for that issue but it's at modified even though it's not ready for release because it's on a branch.
15:47:36 <ttereshc> I agree with the human factor for re # vs closed #, my concern is what daviddavis just said
15:47:59 <ttereshc> + multiple revisions added in redmine for those commits as well and on every rebase
15:48:15 <bmbouter> which branch exactly?
15:48:32 <bmbouter> I don't expect feature branches to live in the main repo
15:48:35 <daviddavis> bmbouter: copy-api-pulp3 in pulp_rpm
15:48:35 <ttereshc> I think it's copy-api, let me check
15:48:38 <daviddavis> yea
15:48:44 <bmbouter> yeah this is the problem then
15:48:52 <bmbouter> feature branches can't be kept in the main repo
15:49:02 <bmbouter> well or we'll get the issue you all are experiencing
15:49:19 <bmbouter> thank you for clarifying the problem for me, I'm with ya'll now
15:49:31 <daviddavis> if we don't put feature branches in the main repo, no one will see the prs, I have to set up travis for my fork, etc
15:49:58 <bmbouter> that's been the recommendation is my understanding, I've enabled travis on my forks
15:50:10 <bmbouter> also they will see the PR when you open it just that the branch is coming from your fork
15:50:18 <daviddavis> not the pulp_rpm team
15:50:19 <bmbouter> and others can collaborate by pushing commits to your branch also
15:50:39 <bmbouter> they can if you open a PR and allow those with write perms to push commits there
15:50:43 <bmbouter> (the default)
15:51:05 <bmbouter> well that's one idea
15:51:08 <bmbouter> here's another idea
15:51:10 <daviddavis> so I have to give the whole pulp_rpm team write permissions to my repo?
15:51:17 <bmbouter> no it's branch by branch
15:51:25 <daviddavis> still seems like a hassle
15:51:45 <bmbouter> I think it's uncommon for branches to live in the actual main repo
15:51:52 * ttereshc is listening to ideas
15:51:53 <bmbouter> generally it's not a workspace
15:51:56 <daviddavis> it's uncommon but not unheard of
15:52:14 <daviddavis> actually, it's pretty common from my experience on other projects
15:52:22 <bmbouter> smaller projects I agree
15:52:24 <bmbouter> but not big ones
15:52:27 <ttereshc> bmbouter, what's the other idea?
15:52:40 <bmbouter> think about how insane this would be for https://github.com/django/django/branches
15:52:51 <bmbouter> not insane, that's not a good choice of word. unworkable
15:53:18 <daviddavis> how so?
15:53:18 <bmbouter> but not unheard of https://github.com/psf/black/branches
15:53:50 <daviddavis> like if django wanted to work on python 3.9 support, I could see them opening a branch for that
15:53:59 <bmbouter> what we had in pulp2 was this problem https://github.com/pulp/pulp/branches
15:54:16 <bmbouter> almost 50 branches and that's after we made a major effort to close a lot of them
15:54:33 <bmbouter> partial work belongs in forks is my claim for simplicity
15:55:02 <daviddavis> where do you see 50 branches?
15:55:09 <daviddavis> I see mostly release branches
15:55:21 <daviddavis> no feature branches
15:55:22 <bmbouter> the count says 49
15:55:31 <bmbouter> we deleted many so the problem was much worse before
15:55:41 <daviddavis> ok, seems like we can police it better
15:55:58 <bmbouter> how about using this feature instead? https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork
15:56:38 <bmbouter> ya'll can work how you want, my interest is to help solve the problem you brought up
15:57:10 <ttereshc> bmbouter, is it for maintainers only or for anyone?
15:57:25 <bmbouter> maintainers only (those w/ write perms is my understanding)
15:57:40 <bmbouter> which I think are eactly the people you already trust to collab w/ on that project
15:58:03 <bmbouter> mdellweg and I have used this feature before to collab, I'll push a change to his PR instead of describing the change in comments
15:58:42 <ttereshc> yeah, I think I used it with dalley for one of the migration PRs
15:58:56 <bmbouter> ok here's another idea (the one from before)
15:58:57 <ttereshc> it might bring us back to commit bit convo though.
15:59:03 <daviddavis> yea
15:59:20 <bmbouter> mini teams should always be thinking abut that anyway tho
15:59:25 <bmbouter> independantly of any other team
16:00:26 <daviddavis> I have a meeting. let's follow up on friday?
16:00:27 <bmbouter> if the work is still in development then don't label the commits with the re, closes syntax until the PR is actually ready
16:00:42 <bmbouter> and label them qhen you squash which is supposed to be done anyway (squashing)
16:00:47 <bmbouter> agreed Ia lso have that meeting
16:00:52 <bmbouter> I had 3.2 topics to talk about
16:01:04 <daviddavis> I can talk after the meeting bmbouter
16:01:06 <daviddavis> #endmeeting
16:01:06 <daviddavis> !end