Gramps 6.1 Planning

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
3 Likes

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

1 Like

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!

1 Like

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!

1 Like

@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?

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.)