Macaulay2
use of the master branch
It has been pointed out that the master branch should always compile for people. Since we have overnight builds, we can have those builds track a development branch, and after success, the development branch could be pulled into the master branch.
We'd have to tell people to direct their pull requests to the development branch instead of master, since github may not do that for us.
In the short term, you can do without forcing people to resubmit. You can select where to merge their pull request: just open the PR, then [Edit] (the the far-right side), then select base:feature/dev from the dropdown. But in the long term, it'd be nice if people pushed straight to the development branch, to avoid merge failures.
When people work on multiple PR's against feature/dev, wouldn't all of them get merge conflicts and have to rebase whenever one of them gets merged?
I see the point of having a dev branch for pushing individual commits so multiple maintainers can collaborate on fixing something while master branch still builds, but I'm confused about this: if a PR (e.g. big like eigen, or just a package update) doesn't get merged until building with it succeeds, why not merge it directly to master? Assuming the requirement for merging was that it builds!
I hope I explained the question clearly.
Well, it's same situation as now, except with "master", so I don't see the problem.
I never rebase. If the upstream master changes, I merge it into my branch.
We don't want people pushing to Macaulay2/M2, except for Mike and me. Others should submit pull requests instead.
The problem with merging pull requests into master is that they might break master, because we don't test every pull request by rebuilding from scratch and running all the tests. The advantage of an overnight build on the development branch is that we can be a little more care-free about pulling and trust that in the morning, an email will arrive if something broke.
And actually, we're going to have to be careful, when merging, to merge with the precise commit that was tested, for the head of the development branch might advance after commencing testing and before merging with master.
@DanGrayson, you can carry out the nightly testing on a staging branch or lightweight tag (e.g. staged/20200509) to avoid conflicts with advanced feature/dev.
I think implementation of this can wait until after we pull the eigen branch request and the cmake request. In fact, the overnight job is now running on the eigen branch, usefully.
Okay, I've pulled #1096 and made a development branch (https://github.com/Macaulay2/M2/tree/development), toward which future pull requests can be directed. We'll merge code from there into "master" only after a build and check succeeds from start to finish on at least one machine.
Reopening this to suggest making the following changes:
-
master→stableormain -
development→unstableortesting
I personally prefer
-
masteras it's the industry standard and meaningful to everyone -
feature/devor justdev(because it's shorter), since it designates the branch's intent. In that sense, "testing" is rather different from "development" and I always associate "unstable" with a release.
You are right that "master" is standard. Indeed, it's the git default branch name.
Actually, our "development" branch is used just for testing, not for development, for when someone makes a pull request from their branch, whatever it is, it is pulled to "development" for overnight testing, and if it passes, then it goes to the "master" branch.
I forgot to mention that the goal is partially to move away from that terminology and all its connotations. trunk is another possibility, though I think stable is even more meaningful, since it points out to users that you won't get any errors on this branch.
By the way, in the repository settings there's an option to change the default branch, so making the switch won't cause any confusions for people cloning the repository. Only Mike and Dan (because they have direct push access to master) would need to run git push --set-upstream origin stable once locally.
FYI: https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/ Yet another suggestion: "primary"
On Fri, Jun 12, 2020, 6:40 PM Daniel R. Grayson [email protected] wrote:
You are right "master" is standard. Indeed, it's the git default branch name.
Actually, our "development" branch is used just for testing, not for development, for when someone makes a pull request from their branch, whatever it is, it is pull to "development" for overnight testing, and if it passes, then it goes to the "master" branch.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Macaulay2/M2/issues/1130#issuecomment-643522905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYAPRX7P62KFH43SH4AFJDRWK4FLANCNFSM4M4OVYZA .
By the way, in the repository settings there's an option to change the default branch, so making the switch won't cause any confusions for people cloning the repository.
It will also cause (immense) confusion for those who have cloned in the past, since "git pull" will either stop working or will stop yielding new commits.
Why immense? I tried this on a test repository and git guessed what had happened and offered a useful suggestion. With an announcement to the Google Group, along with announcing that pull requests should be make to development (or testing or unstable or ...), I'm sure people will appreciate the change. If nothing else, it signifies the fact that the default branch is "stable".
It's a good change, Dan.
On Mon, Jun 15, 2020, 8:50 AM Daniel R. Grayson [email protected] wrote:
By the way, in the repository settings there's an option to change the default branch, so making the switch won't cause any confusions for people cloning the repository.
It will also cause (immense) confusion for those who have cloned in the past, since "git pull" will either stop working or will stop yielding new commits.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Macaulay2/M2/issues/1130#issuecomment-644147414, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYAPRS7IG363TQWXL7EBEDRWYRLJANCNFSM4M4OVYZA .
It seems like potential good names for a replacement to master would be: stable, main, primary. I lean towards one of the first two.
If git handles the change gracefully, with a suggestion on what to do, that, combined with a note on our google group, the change might not be too confusing.
Why risk any confusion, when we aren't even using the word "slave", and there's no danger that anyone would regard our failure to eliminate the word "master" as reflecting an accepting attitude toward human slavery?
Why risk any confusion, when we aren't even using the word "slave", and there's no danger that anyone would regard our failure to eliminate the word "master" as reflecting an accepting attitude toward human slavery?
Like I said, because "stable" carries more information, as it provides a promise that the default branch is stable and has gone through a testing phase.
And also because people will appreciate it.
Github now supports renaming an existing branch seamlessly:
- Re-target any open pull requests
- Show a notice to repository contributors, maintainers, and admins on the repository homepage with instructions to update local copies of the repository
- Show a notice to contributors who git push to the old branch
- Redirect web requests for the old branch name to the new branch name
- Return a "Moved Permanently" response in API requests for the old branch name
As Mike suggested, stable, main, or primary are all good options. stable pairs well with development or unstable semantically. Thanks to Github, making the change doesn't disrupt anyone. We can also have testing, if there's a need for a branch between development and stable.
This issue never reached a conclusion. Here is a summary of suggestions:
-
main,stable,release, orprimaryinstead ofmaster. -
development,unstable, ortestingfordevelopment
I've done this on a few repositories and, thanks to GitHub, there is zero disruption to people's existing clones.
cc: @d-torrance
I think development might as well just stay development.
I have no strong opinion on the renaming of master. main makes sense, I suppose -- it's the new GitHub default -- but any of these others seem fine, too. Whatever its name, I think it should point to the most recent release tag.
