I was wondering what the difference is between the Master repository and the gramps52 repository. Maybe I’m wrong, but I thought that the master was development repository and the gramps52 was the released version but I noticed that in the 52 repository says that the branch is 35 commits ahead and 47 commits behind. Shouldn’t the 52 repository not be ahead of the Master. I’m teaching myself python so I can understand the gramps code and don’t which repository I should be using since there is a large mismatch between commits on the two repositories.
The gramps52 branch will be ahead of master when it has some bug fixes and translations that have not yet been merged into the master branch. This probably indicates that we are due for another maintenance release.
1 Like
Nick has already explained why there is a difference in the two. Since you said you’re starting out with Gramps development let me add to that, which may help you decide where you might want to start:
Personally I have several Gramps branches in my dev environment and switch between them often because each task may require code from a different branch. It’s best to use the code branch that is closest to the bug you’re fixing, or feature you’re enhancing (see Gramps branches)
Most of the time I tend to operate on the maintenance/gramps52 (or gramps51) branch, for example when I’m attempting to reproduce a defect and fix a bug especially if the bug is reported in that branch. Note that if you pull the gramps52 branch you will be ahead of the release (currently 5.2.2), but you can pull gramps52 branch tagged 5.2.2 so that you can get code that matches it exactly.
Smaller enhancements if accepted for the 5.2 release may also be developed there. However major enhancements and or issues requiring string translations are likely not suitable for a maintenance branch and should be developed on a branch from master.
If you run into more questions, feel free to post. The Developer Portal has a lot of useful info, although it can be spread across several pages and you have to pull it together.
1 Like
I’m using pycharm to look at the code and I notice a lot of warnings. Looking at the Master repository, I see the migrate code to black pulls which removes a lot of these warnings, but hasn’t been put into the 5.2.2 code and was thinking about adding them to my local code to play around with. Also some of these pulls are features I would like to use. Guess the worst I can do is break the code, but being retired I have lots of free time.
We have had a few experienced GitHub users (although not experienced Gramps Developers) make tentative noises about volunteering to shepherd developers through the GitHub process. (see the [Gramps-devel] any volunteers to shepherd Gramps (new and update) addons through GitHub? thread in the Gramps-Devel mailing list archive.)
But they’d suggested a mentor from the Gramps Team as they come up to speed. And it was pointed out that the scope of help needs to be defined:
- help getting to the point of submitting valid GitHub PRs (no Gramps coding beyond passing the Black and Lint tests)
- the channel for kicking stalled PRs up to authorized Developers to push
- a method to raise concerns about workflow that stalls progress
- a team member to fix Developer docs (sphinx and wiki) that are incorrect, outdated or could be streamlined.
(Some open source projects experienced a withering of their teams that vetted new team members and authorized core team members. So the backlog of PRs can’t be addressed until there were new authorized members. But the volunteers couldn’t be authorized due to lack of core members. We should try to prevent Gramps-Project from falling into that trap.)
John Ralls and @codefarmer brought up good points about Gramps-project knowledge.
Potential GitHub moderator team
- Al Stone
- Sebastian Csar
I started a topic on gramps on github but never got to follow up on it due to going through cancer treatment and it timed out.
I understand what was being said about the differences between the Master and maintenance branches. It still has me confused.
To me it seems that the master branch should always be ahead of the maintenance branch. As bug fixes come out, they both should be updated. Any new features are added to master, when its time for a new version, the master is copied over to a new maintenance branch and the whole process start over again. I know I’m probably overthinking this. Years ago I use to program in C before github when revisions were used. Now I’m trying to wrap my head around Python.
Hope your treatments are meeting with success. Re-opened your topic from 2020 and merged this new topic.
Note, due to Nick clarifying that the Master branch for the Gramps addons-source repository shouldn’t be the target, @GaryGriffin merged a huge number of commits into its maintenance/gramps52 branch. (Thanks Gary!)
My understanding is that the master branch of the Github gramps-project/gramps repository is for new feature development and compatibility changes for required package version updates. Constantly merging in changes from the maintenance branches could cause conflicts. (Sometimes, new features are designed to retire the workarounds added to Maintenance releases.)
The decision to merging each commit in Maintenance branch changes is based whether it conflicts with the Master. The Developer leads decide which commits from Maintenance are needed in the Master and when.
@moorob Wishing you the best in your treatments and recovery.
You’re not overthinking! A typical git branching strategy encourages commits directly to master and cutting branches for releases. However, Gramps’ git branching strategy is a bit different from that (the process is explained in the links I posted in an earlier message). This is why you’re seeing more commits, especially fixes, in the maintenance branches of both Gramps and addons repos.
Some work is required to bring the master branches of both Gramps and addons repo in sync with what’s going on in maintenance, but I am not sure what the plan is for that.
[EDIT: Looking at git history, Nick has merged gramps52 to master on July 26, so the branches should not be too different now]
If you’re stuck in a particular situation, feel free to post here and maintainers/volunteers will answer. If you just want to get started, pick the branch that makes it easier for you to work in, it can be rebased later. As a rule of thumb, If what you’re creating is not a major feature/enhancement and does not require string translations, create a branch from maintenance/gramps52, otherwise create a branch from master.
There are options for which branching strategy to use for a software project. Gramps documents that fixes should go in maintenance branch and that they will be merged into master. However, the longer that merge takes the more the branches diverge and cause headaches for the person who has to merge the changes to master.
It would seem to me a rare exception when code that goes into a maintenance branch would not need to be merged into master.
I’ve shared my view on the branching strategy with @Nick-Hall in a private thread about outstanding PRs, and I’m happy to participate in continuing discussions.
1 Like