Gramps 6.1 Planning

Development
1

Gramps v6.1 non-draft Open PRs

There are currently 42 open non-draft PRs (Pull Requests). These would make the foundation of Gramps 6.1.

I’ve broken them down into 3 groups:

  1. Those that should be reviewed+merged first either to cut down on merge conflicts, or to allow additional PRs and development (gramps desktop and web)
  2. Regular bug fixes and enhancements
  3. Items that should be merged at the end of the 6.1 development process

I suggest we review and merge the PRs in this order. If you are working on something (draft or otherwise) please leave a message on this post. If you have a suggestion for changing the order, let me know and I will edit this list.

Group 1:

# Title Author +/- Review
#2195 Refactor proxy system: two-layer include/sanitize filtering dsblank +1173/-2059 —
#1934 Minimal code changes to support type hinting of db methods stevenyoungs +323/-178 —
#2184 Add type hints to gen/lib classes and fix filter rule type errors dsblank +370/-52 —
#2128 Protocols for typing of Gramps objects DavidMStraub +645/-1 —
#2178 Add JSON field indexes on json_data handles dsblank +52/-0 —
#2180 Live filter UI updates, responsiveness, and O(n²) fix dsblank +100/-21 —
#2162 Add config to allow ignore XML mediapath dsblank +4/-1 —
#2160 Optimizer: skip loop when all rules are optimized dsblank +81/-40 —

Independent bug fixes and/or enhancements:

# Title Author +/- Review
#2182 sort_key: replace hexlify with getSortKey() bytes, drop binascii import dsblank +243/-6 —
#2181 edit INSTALL ClmntPnd +9/-2 —
#2177 Add register_override API so DB backends can use optimized implementations dsblank +289/-1 —
#2176 FamilySearch Integration SourceAirbender +18353/-7 Changes requested
#2165 Save filter dates in locale-independent format dsblank +44/-3 —
#2164 Better default Tag colors dsblank +82/-4 —
#2161 Add order change UI for rules in filter editor dsblank +247/-4 —
#2154 Improved Manage Family Trees behavior when deleting trees: preserve sort column and better next item selection hgohel +45/-2 Changes requested
#2153 Use filter.apply() rather than apply_to_one() dsblank +217/-222 —
#2150 Add tearDownClass method to cleanup after unit test hgohel +9/-0 —
#2149 fix: add resilience to set_birth_death_index() for storage backend failures mahula +47/-13 Changes requested
#2142 subdirs and comments in narweb css files SNoiraud +20/-4 Changes requested
#2132 Avoid opening a Citation when dragging or selecting an existing one roptat +2/-38 —
#2131 birth/death estimation improvement Rak424 +43/-1 —
#2111 Graph algorithms dsblank +949/-300 —
#2100 NarrativeWeb: Add non-sharable notes to media SNoiraud +161/-18 —
#2091 Add a favorites sidebar and all persistent sidebar SNoiraud +377/-0 —
#2084 Internet indexing for the Narrative Web SNoiraud +11/-2 —
#2083 Pass an object rather than a handle to the note editor callback #2 stevenyoungs +28/-21 —
#2050 Fix icu/PyICU exception handling in narrated web report martin-schwenke +8/-8 —
#2037 Add a HasNoteTag filter rule stevenyoungs +466/-0 —
#2036 Add HasNoteType filter rules for Media and Repository objects stevenyoungs +96/-0 —
#2010 Fix IsMoreThanNthGenerationDescendantOf.init_list() typing stevenyoungs +3/-5 —
#2005 Add a “References” tab to the editfamily dialog stevenyoungs +57/-0 —
#2001 New calendar SNoiraud +318/-5 —
#1998 Allow invalid dates in the relationship graph SNoiraud +12/-2 —
#1988 Fix man page updates Nick-Hall +10/-10 —
#1979 Use https instead of http stevenyoungs +269/-269 —
#1963 Allow filters to be cancelled dsblank +291/-172 —
#1919 Add type hints to db classes stevenyoungs +1530/-919 —
#1882 Refactor Relationship Calculator and Add a Searchbar stevenyoungs +208/-282 Changes requested
#1873 Improved Descendant Tree and Ancestor Tree new features dave-khuon +166/-6 —
#699 FR10850 V2: freeze/unfreeze button per gramplet SNoiraud +70/-16 —

We probably want to save these until the end, as they will cause version 21 databases to be unavailable in master without upgrade:

# Title Author +/- Review
#2141 Version 22: Coalesce event role types stevenyoungs +62/-2 Changes requested
2

Thank you very much. Even for a non-developer it is interesting to see what to expect for new releases.
But it also raises some questions.
What about all the feature requests in the Gramps Bugtracker (MantisBT). Is there any formal prioritisation rules, for a feature request to be considered for the next release?
Users often asks for a new feature or improved UI in the Gramps Discourse categories ‘Ideas’ or ‘Help’. Is such requests considered or are they ignored until there is a feature request in the Bugtracker or a Pull Request in Git?
Is there any means to raise attention for a particular request, or could/should we have a voting for which feature requests to prioritise for the next release?
TIA
Claus

3

Not as far as I am aware. I guess developers work on whatever they are interested in.

The PRs in git are of course made by developers. So if their contribution is seen as good, it is generally accepted. Regarding other feature requests…

It would be wonderful if the users could self-organize a list of priorities that they would like to see added to the next version.

I, for one, would be glad to work down a list of prioritized features for inclusion!

4

I think it might help if developers could identify, and discuss the implications of, technical changes that need to happen in next few years. For example, “we should move from GTK3 to GTK4 (or whatever) by x date, and doing so will give us the ability do these new things, and make it easier to improve these old things”.

Maybe AI can also help analyze the backlog. Many requests are already marked as “related” but it might identify more connections.

Then, developer input could again be helpful, for example “each of the issues in this group would individually be a pain in the neck and not worth my time, but if we changed how the such-and-such worked, then it would be straightforward to implement them.” Or another example, “the requests in this group are probably not useful to many people besides the requestors, but if we changed x, then users could tweak things to their desire.”

Thank you!

5

@Nick-Hall @dsblank @SteveY and other Gramps developers:
When a PR introduces a breaking API change that may end up breaking 3P addons, what should be done to ensure minimum disruption?

Case in point, for PR #2083 there are comments indicating such a breaking change and that the PR should be targeted to Gramps 6.1.

Should the author of the PR add a commit in the same PR to fix the addons so that the build remains stable?

6

Our goal for Gramps 6.1 is that we will have proper checks not only for the correct number of arguments that are passed into functions, but that they will also be checked to be of the correct type. My suggestion would be to add that requirement to the 3rd party addons for 6.1 (using mytype) so that it will automatically catch and prevent any such addon from being accepted.

It will be the addon’s author’s responsibility to either fix any breaking change, or their addon just won’t be accepted.

(In technical terms, an addon commit can’t be in the same PR as that is a different repository, but I get your meaning.)

7

I have to disagree. If the core developer breaks an API, I think it is upon them to fix both any occurrence in core as well as addons. I could imagine one core PR for the commit and to cover core breakage. And an Addon PR to cover all breakage there. The Addon PR could be part of the migration path when a new release is created.

8

I believe we agree that the author of the core PR should ensure that the addons work.

I wasn’t thinking that because addons-source is a separate repo, it has to be two separate PRs as Doug reminded me :slight_smile:

9

Actually, in this particular case the developer is fixing an API in a proper way.

I think it is asking a core developer to do too much to figure out what a 3rd party addon should do.

I think it is perfectly reasonable to ask an addon contributor to maintain their own work.

10

We had a long discussion about features when Nick posted the Roadmap for 5.3/6.0…

At least the first half of it is about features wanted…

I will again mention my 3x two cents.

  1. Main-/Sub Events
  2. Events on Places
  3. CSL support and a hierarchical and extended feature for Repositories/Sources/Citations (RSC)…

In addition, I do not know how much more all of you devs work with moving logic from the frontend to the backend for speed, but I think that is something most users with larger databases still need more of… (speed)…

Ooh, one more thing…

Regarding time periods: please move away from the GEDCOM logic ASAP…

But as a whole: My earlier posts in the roadmap thread outline the structural backend changes needed for long‑term performance — JSON‑based storage, proper indexing, database views, and multi‑threading support.

In addition, I’ve already described 3–4 core features that would lift Gramps several floors in the humaniora‑oriented research field.

These are still my priorities.

11

Our current policy is that core developers to not have to update third-party addons after an API change. However, in the past, some developers have updated addons as a courtesy.

12

Also, not very often do we create things that need to be fixed that the addons use.

But using the mypy and other tools will make this easy to find problems, which we have never used before, and have created issues.

13

In this case, as the PR author, I don’t believe that it will be easy to identify which, if any, add-ons are broken by the change. You would need to identify the expected type of an argument to a callback function in the add-on. The breaking change was necessary to fix core gramps which is broken in 6.0 and earlier versions.

14

@Nick-Hall it seems like the bug fixes that are applied to a maintenance branch are not immediately applied to master. This makes it difficult to work on master. Is there any reason not to immediately apply a maintenance fix to master?

15

The maintenance branches are merged into the master branch on a regular basis. The last branch merge was on 20th March and there haven’t been any bug fixes committed since then - just some translations and changes to the AIO build.

I can merge at any time when there is a reason to do so.

16

@Nick-Hall it would be helpful to me if the AIO fixes in gramps60 can be merged into master sooner rather than later.

17

I’ve just merged the gramps60 branch into master again.

18

@Nick-Hall What is your plan for starting to merge the 6.1 PRs into master? There are going to be lots of merge conflicts as we go, and I for one could start working on a 6.1 addon once we start getting the above merged.

19

I usually do this in two passes. Firstly, I merge the small PRs that are easy to review and test. They also are less likely to have conflicts. I have started this process already.

Then I review the larger PRs and decide what will go into the next release. This obviously takes longer.

I leave merging the large PRs until shortly before creation of the new maintenance branch. In the past I have had problems merging the maintenance branch if this is done too early.

After this I create the new maintenance branch, a new addons branch and point Weblate at the new branches. This will be about three months before the planned release date to give the translators a good amount of time.

The current roadmap was to plan for the next feature release around 1 Oct 2026. However, I am still in discussions with FamilySearch and our plans may change.

20

To be released earlier than Oct, or later?

What are these discussions like? Do they involve developers from our side? I’m the only one so far that has started reviewing the 19k lines of code, and don’t really know what the goals or timeframe is. Feel free to invite me to any FS conversation.

I’m also worried that some of the speed improvement PRs might not get in because of the focus on FamilySearch.

Can you add some transparency to the FS conversation?