Suggestions for the Orbiter Repository and Orbitersim Organization

[n72.75]

I have two small suggestions for the Orbitersim organization on GitHub, that I think will make workflow a bit easier/safer.

1. Add regular contributors as "members" (not Owners), to the Orbitersim organization. There is no limit to the number of members that can be in a GitHub organization, so no issue there. Right now people who aren't members can't: request reviewers to pull-requests, add labels (bug, enhancement, etc) to issues or pull requests, review or approve pull requests.
2. Protect the main branch so that no one (not even "Owners") can commit directly to it or merge pull-requests into it without an someone approving a pull-request. We've been very good about checking each others code. This shouldn't really add any extra work, but it adds a lot of safety.

I can only speak from my experience with NASSP (and being a fly-on-the-wall to [open]simh and the pdp10 organization), but it works quite well.

You can look through the closed NASSP PRs https://github.com/orbiternassp/NASSP/pulls?q=is:pr+is:closed , and see who was a reviewer, comments, issues, milestones, etc.

The PDP-10 organization has this for members: https://github.com/PDP-10/-READ--THIS-

 

[jarmonik]

2. Protect the main branch so that no one (not even "Owners") can commit directly to it or merge pull-requests into it without an someone approving a pull-request. We've been very good about checking each others code. This shouldn't really add any extra work, but it adds a lot of safety.

I suppose that could be tested how it works. Many pull-request are so technical by nature that it's difficult for anyone without special knowledge about the topic to judge or verify the content in detail. But, of course, the reviewer would be a second pair of eye's to review a content that might be harmful in someway like compromising the compatibility/integrity of the Orbiter.

 

[n72.75]

I suppose that could be tested how it works. Many pull-request are so technical by nature that it's difficult for anyone without special knowledge about the topic to judge or verify the content in detail. But, of course, the reviewer would be a second pair of eye's to review a content that might be harmful in someway like compromising the compatibility/integrity of the Orbiter.

Yeah, I think actually combing through the code and finding bugs before it's merged is more of a secondary benefit. For example, I'll definitely look through the code for graphics client updates, but I probably wouldn't see anything obvious from just the code, although I am in the habit of pulling and building locally to test stuff.

My intented goal with this was more along the lines of letting contributors be "members", so that we can use features like tagging, assigning members to projects, milestones (e.g. "2024 release"). And to do that, we would need to enable branch protection. It also protects against accidents (e.g. "oops wrong git command").

 

[jarmonik]

My intented goal with this was more along the lines of letting contributors be "members", so that we can use features like tagging, assigning members to projects, milestones (e.g. "2024 release"). And to do that, we would need to enable branch protection. It also protects against accidents (e.g. "oops wrong git command").

I have never used Git before the Open Orbiter so I am a bit unfamiliar with a lot of things there. But I do support the idea to make it easier and better to use. Currently the main branch is protected so that no direct commits can be made there only pull requests. It could be helpful if active developers could directly commit to a branch in 'origin' without need to reroute commits/pull-requests through forks. If I need to do something through my fork, it's getting messy.

 

[n72.75]

I have never used Git before the Open Orbiter so I am a bit unfamiliar with a lot of things there. But I do support the idea to make it easier and better to use. Currently the main branch is protected so that no direct commits can be made there only pull requests. It could be helpful if active developers could directly commit to a branch in 'origin' without need to reroute commits/pull-requests through forks. If I need to do something through my fork, it's getting messy.

My workflow leans pretty heavily on the fork and main repository relationship, not that it necessarily has to for everyone, but that seems to be the more common way to do it.

I keep Orbitersim\orbiter as my "upstream" and n7275\orbiter as my "origin".

I never do any work in my "main" branch, because I want this to exactly match the current state of the main repository. I keep main up to date with:

git fetch upstream
git checkout main
git merge upstream/main --ff-only
git push

The "--ff-only" prevents git from creating merge commits, when you really only want it to fast-forward and stay even, not become "X commits ahead".

Then I'll create a feature branch in my fork based on origin/main and work on it. When new commits are merged into main, I update my feature branch by first updating origin/main then merging origin/main into my feature branch. Before I mark something as ready for review I will "rebase" the feature branch onto an updated main and squash any small commits into larger single commits.

Community branches in Orbitersim aren't a bad idea. Those will also require contributors to be members.