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