What to do with Patches and Plugins marooned in MantisBT?

While validating issues in MantisBT (or when reading Maillist archives or Discourse threads), I occasionally find a useful code snippit, patch or Plugin in the Notes that seems to have gone nowhere. And then I soon lose track of them. (Once I ran across a promising change that had a PR showing committed to a branch that I did not recognize. Maybe it was a clone in a personal repository. I cannot find it now.)

Another example is 9925 where Notes attach an Ancestry dot com gramplet and an expanded GEDCOM export core module:

Date User Summary
2017-04-10 19:13 Sam888 File Added: ancestrygramplet.gpr.py
2017-04-10 19:14 Sam888 File Added: ancestrygramplet.py
2017-04-10 19:14 Sam888 File Added: exportgedcom.py

How should these be handled so that the contribution to Gramps is not lost?

And, if that includes consolidating the items somewhere, how do we mark the source items so we don’t do redundant consolidation work?

The associated pull request #1233 has already been merged, so feature request #9925 can be closed.

If the code is an addon, then the author can request that it is included in third-party addons repository. This will almost never be refused unless the code is malicious or updates user data without making it clear that it is doing so.

We don’t normally accept patches. New features should be submitted as pull requests. It is strongly advised that any large changes are discussed on the gramps-devel mailing list first.

No disagreement with Nick-Hall, do agree that it would be nice to have a way to leave markers on some things… Are the MantisBT tags adequate?

I have marked some issues with PATCH, that have been rarely needed workarounds that will become unnecessary when/if new release updates a library or support program.
(example dot.exe which is graphviz version 2.40.1 (20161225.0304) for Windows which might get upgraded in 5.2 ?).

Could you create the tag MAROONED or maybe ORPHANED_INSIGHT or HISTORICAL_INSIGHT_CONSOLIDATED

Feel free to create any of those tags.

The problem with tagging the report is similar to what happened here. The report had TWO different items: a Gramplet prototype and a change to a module.

The PR @Nick-Hall referenced covers the exportgedcom.py

But that leaves the AncestryGramplet still marooned. And while Notes with text have a permalink generated automatically, the Notes that are only attachments do not.

In that particular case, Sam posted an experimental gramplet in ADDITION to the patched GEDCOM export module from Tom Samstag’s AncestryCitations repository. Which is discussed in the “Gramps and Ancestry hints” thread of the Gramps Users maillist.

With the new “experimental/Beta” statuses and “Expert/Developer” audiences filters being introduced, it is reasonable to actively recruit and post even risky addons … maybe to a separate location than the addons-source repository. Developers should be more willing to post their contributions in the Gramps-project GitHub space, indicating it is FULLY in Open-Source and others are welcome to fork it. (Even though Tom embedded the GNU GPLv2 license in the source posted to his public repository, I’m betting a lot of us still feel like we need permission to play with that code.)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.