It seems like it would be good to have all the bug fixes get a month of widespread testing so any tweaks can be added before 5.2 goes into lockdown. Then all the issue reports are more likely to be focused on new features instead of mixed with bug fix tweaks.
@prculley I’m having troubles getting an overview of what is planned for next releases (5.1.4 and 5.2) and what work is still open. Where can I look that up?
There are several places, but they seem to differ in the issues listed:
In theory, the wiki Roadmap is supposed to indicate plans for the next major version. But this is often not kept up to date, and there are many PRs for enhancements that are never put up on the roadmap.
Maintenance releases have no overview of plans for what is included (other than the general policy to only fix bugs or enhance translations). But it isn’t too hard to count (manually) the number of commits since last release and bug PRs that might apply to the maintenance release.
I’ve never payed any attention to Mantis roadmap, and issues only get attention as some developer sees fit. For myself, I try to attend to bugs that I can actually solve, and that appear to be more or less likely to affect the user.
I’ve grown tired of trying to get major enhancements into place in the mainline Gramps, as several I have done are still pending after years of work. Which is kind of a disincentive.
Note that our “Installation stats” are strictly opt-in and therefore we believe the number of actual users is seriously undercounted. Nonetheless, the page does give some information on user configurations. IE, range of operating system versions, python versions in use, etc.
I’m happy to help if I can even though Dave Evans is the official maintainer on MacPorts.
If that is available for GitHub, we could get a regular report of the times that the Plugin Manager polled the Updated Add-Ons list. I suspect that it is only downloaded when it is newer than the timestamp of the cached file.
Updating the list could get us a better & fresher count of active users than installer downloads. Naturally, it wouldn’t count users who don’t check for Add-ons but it would give a better idea of those installed from distros.
If it IS possible to breakdown by agent & OS, it might be possible to give distinction to Gramps as an agent with a versioning identifier for each installer type.
We could have a real idea of whether Gramps is in widespread use.
@emyoulation Thanks for the ping! As long as there are no Gramps XML schema changes, Betty will be fine. I’m hoping to introduce more API-level integration between Betty and Gramps sometime soon (which will make it easier to run some automated tests against upcoming Gramps versions), but I’m currently swamped with building automatic package releases and the GUI, so it’ll be later this summer before I get around to that.
I find them unintelligible because the sections on MacPorts and Homebrew don’t actually tell anyone how to install nor point towards a Gramps download. They just point towards the generic sites and leave the user fumbling around, looking for something labeled ‘Gramps’.
If you look at the PortableApps section for Windows, that section also describes the PortableApps project with a link to the generic site. But the majority of the text instructs how to use the installer and hyperlinks to the downloadable file directly.
(And I am not fond of superscript footnotes links inside webpage. It has the reader jumping around the page and undermines confidence.)
Just to clarify, MacPorts and Homebrew are systems for finding, installing and upgrading software packages. Thus, neither will “point towards a Gramps download”. For MacPorts, if any of the 200 or so support libraries or modules required by Gramps are updated, MacPorts will update just that package. The user does not have to download a complete Gramps dmg and reinstall. (Homebrew is different for packages like Gramps.)
The advantage of a system like MacPorts is when you have a bunch of software packages installed that way. With a couple of commands, you can find if any of the packages have been updated and install them all at once.
Ah, ok. My own feeling is that since there’s already a DMG to download, the MacPorts and homebrew links are just there for users (like me) who already know what those things are and how to use them. It’s a lot to ask for support for a third-party set-up like those. People who know them will know what to do.
I only looked at the macOS section when multiple users on Facebook said they could not get Gramps to install on their macs. They reported no problem with the process restated more simply.
The nature of MacPorts & Homebrew should be made more evident. The Download page is serving two masters poorly in this case. There are 2 categories of users: experienced who just need the links; and, new users who need hand-holding.
There’s too much newbie-oriented clutter for the experienced users. And the amount of unrelated information to the newbie’s OS causes confusion and anxiety.
We’re well passed the point where there should just be a 1-screen-full downloads page (offering the files) with branches to separate OS specific tutorial pages. (Those pages could funnel back to a ‘Gramps for first time explorers’ or, alternately, the Reference Manual wiki.)
That sounds… risky… to me.
I can see updating the post-install dependencies – like GraphViz. Those are less tightly integrated.
But since Gramps is a Linux project that is ported to macOS and Windoze, it seems likely that there are tweaks & workarounds that were needed. And the entire project lags behind the “bleeding edge” because (even in the unlikely event the newest libraries were bug-free) the Gramps code or dependencies are not fully compatible. There is code that would have to be reworked.
I was referring to the Gramps wiki. All my tweaks on that download page have been for the Windoze. (It’s been almost 2 decades since my years of supporting Macs & writing tutorials.) But the wiki needs to improve clarity…
Take the Download footnote for MacPorts:
 The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading open-source software on the Mac operating system. https://www.macports.org/ In order to do that run the following command: port install gramps see: Mac OS X:Build from source:MacPorts
The generic stuff about the MacPorts Project is fine in the footnote. It is merely background information.
But the specific command line & link to the Build page are actionable. They should be up in the body of the Mac section.