Collaborator Access #1125
Replies: 9 comments 2 replies
|
Hmm no, I think I prefer that routine collaborators join the CAS community and be able to create their own branch inside casact. For those that are just submitting a one off PR can stay on their own fork. Being on the same repo actually makes reviewing easier because you can switch to that branch to do what is needed. I couldn't figure out a way to review a PR off a fork without doing a bit of extra work to bring everything back to the same repo. What do you think? |
|
I anticipated it was a convenience thing - I came prepared with a response! There's a way to check out a fork's branch via my IDE (the red circle has a dropdown to check out), I think if you're using VS code you should have something similar: 
I used to think I had to clone and then check out if I wanted to do a deep dive, which was annoying. But there's an IDE feature that lets me stay in my window. Hope that helps. Reason I brought this up is because I do want to keep the official branches tidy and manageable. If we let non-codeowners create branches on origin, we'd have to prune frequently and deal with abandoned branches. It might even be that the codeowners shouldn't be creating non-protected branches on origin. When I checked pandas, the big maintainers merge from their personal forks. |
|
That's cool, let me look into this in my IDE. On a separate now, there are actually a lot of old branches that probably could be deleted. And I agree that we don't just let anyone in to create new branches on origin, I do think we want to include consistent contributors to be included in the same circle? Pandas is much bigger, and the only branches I see on origin are by release versions. I don't think we are that mature to do that yet? I do enjoy being able to create a new branch on origin. |
The only time that it's created extra work is when there are conflicts between the pr branch from the fork and main. but the PR raiser should be taking care of those anyway. |
|
@genedan #1155 is a good test for our future branching guidelines. I was originally going to suggest that we merge into the same branch, and raise a PR from that joint branch into main. The problem, as I thought more about it, is that we'd have to get Ken to approve. how do you want to do this? |
|
That is both another benefit and hurdle, if we all work on casact's branches, we all have write access, and all of us can commit on top of one another, but ya, once you make a commit you cannot approve a that same open PR. An easy way to get around this is to withdraw and resubmit the PR. In fact, I think if the PR has too many subsequent commits, it should be withdrawn and resubmitted. That said, I still think core contributors should all be doing dev on this community instead of on a fork. |
|
I read over a branching strategy guide hoping to get some guidance on whether codeowners should be making branches on their own forks or if it was okay to be making them on casact. I didn't find any so I think it's just a matter of group consensus. While my opinion is to limit casact branches to main and short-term protected branches for complex issues (just looks cleaner to me), it's not a super-strong one so I'm happy to go with the majority opinion. |
|
But yes, we should branches organized, delete stale/old branches. |
|
when i sleep at night, i dream of a day when this package is so popular that we always have a dozen contributors working from all corners of the globe at all hours. in that inevitable future, github action bandwidth does become the bottleneck if too many people are creating branches right here. |
|
I think most enterprise/corporate teams use the branching workflow (working on the same repo but different branches), and most real OSS projects use the forking workflow. I still think we should do the branching workflow (for now), because one of the great advantages is that if you are on the same "team" on the repo, you would all have write access to all branches. You can pick up work as needed. If we do the forking workflow, you typically do not have write access to another person's fork (would need to clone on new branch etc). |
|
reading through Gene's link from #1129 and also doing some of my own research, i do think we should adopt a hybrid approach.
|
Uh oh!
There was an error while loading. Please reload this page.
@kennethshsu i recall at one point in time that you preferred we work on branches in the upstream/casact. outside the 4 code owners, no one else appears to be able to create or edit branches on the casact repo. all the PRs you see from others are from their fork. is this what you had envisioned? want to make sure we are on the same page.
All reactions