Changes

Jump to: navigation, search

5.1 Roadmap

1,326 bytes removed, 00:17, 16 June 2019
Schedule
{{man note|This is a guide only.|Because of the nature of a volunteer-driven project, it isn't possible to say with any certainty what will happen in the next release.}}
 
This page collects possibilities for the 5.1 version of Gramps
| 01 Jun 2019 || String freeze.
|-
| 15 ?? Jun 2019 || Final release.
|-
|}
* http://oss-watch.ac.uk/resources/governancemodels
* https://opensource.guide/leadership-and-governance
 
====Decision:====
 
We will continue with the benevolent dictator model. The Architect will define the project's strategic direction and have the final say in decisions. However, if a contributor regards a decision as unfair or contrary to the projects goals, an appeal can be made to the Administrator.
 
The current Architect and Administrator are listed on the wiki Team page:
 
* https://gramps-project.org/wiki/index.php/Team
===Procedures for branch merging===
When should they be merged?
 
====Decision:====
 
We will continue with the current process and also extend it to the addons-source repository.
 
Branches should be merged before they diverge significantly, but no exact timing was agreed.
 
Paul Culley will co-ordinate this task. Other developers are more than welcome to help out.
===Pull requests for significant changes===
How long should a PR remain open for reviews, comments and testing before merging?
 
====Decision:====
 
Almost all changes should now be made through pull requests. The following are exceptions:
 
* Making a release
* Branch merging
* Updates to translations
* Updates in release directories
* Emergency fixes
 
Bug fixes in maintenance branches should be left open for at least 7 days for comments. After that, if no objections have been raised, any developer is allowed to merge the PR including the author. The developer merging the PR should test it first. Code reviews are encouraged. Any contributor can easier express approval or concern by reacting to the initial comment with either a thumbs-up or thumbs-down emoji.
 
New features in the master branch should be left open for at least 14 days for comments.
==Dependency upgrades==
==Database model changes==
Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here.
 
* '''Enhancements to the place structure to support GEDCOM-L [http://wiki-en.genealogy.net/GEDCOM/PLAC-Tag PLAC tag]'''
** Allow multiple place Types with date for each
** Deal with 200+ place types
** Allow multiple postal codes and other attribute like data, with date for each
** Allow places to have attributes (for above)
 
Suggested changes to implement the requirements above:
 
* PlaceName
** Add a list of PlaceAbbrev objects. A PlaceAbbrev object should consist of a some text and associated type (PlaceAbbrevType).
** Add a citation list.
 
* PlaceRef
** Add a hierarchy type.
** Add a citation list.
 
* Place
** Replace the place type field with a list of LocationType objects. A LocationType object should consist of a date, PlaceType, and citation list.
** Add an attribute list.
** Add an event reference list.
==Major goals==
This section lists main goals developers want to achieve. Major goals should be started in a GEPS branch. Major goals require a developer and a reviewer.
* '''[[GEPS_043:_Improving_GEDCOM_support_for_Places|GEPS043]] Improving GEDCOM support for Places'''* ✔ '''[[GEPS 044: Replace Deprecated Gtk.UIManager|GEPS044]] Rewrite UIManager code to avoid using deprecated methods'''* '''Store objects as JSON rather than pickled blobs''' See feature request #{{bug|9392}}. Previously discussed on the list. [https://sourceforge.net/p/gramps/mailman/message/35406641/]* '''Remove raw methods from database API'''
==Minor goals==
Suggestions:
 
* ✔ Change default database backend to SQLite for all users [https://sourceforge.net/p/gramps/mailman/message/36148493/][https://github.com/gramps-project/gramps/pull/827 PR#827]
 
==Rejected Changes==
* '''Add citations and attributes to notes''' Sources on notes previously rejected. [https://sourceforge.net/p/gramps/mailman/message/28754193/]
* '''Some "attributes" we have currently don't match up well with GEDCOM''' When Gramps originally was conceived, these attributes did not have dates, places, and media attached (Gedcom did not have these either). The last version of GEDCOM allow this. Dated attribute would help, or just make these into Event/Fact types.
* '''Change links in notes to hard-references''' Decided against in original design discussion. [https://sourceforge.net/p/gramps/mailman/message/25194039/]
* '''A method to mark objects as "used"''' ''TODO'' tagged items work like this now, maybe another standard tag?
* '''A way to attach objects to the database itself''' Something like the "Researcher"/"Database owner" but including other data. See {{bug|6365}} & {{bug|8734}}
* Recommend SQLite3 (as default) for all users [https://sourceforge.net/p/gramps/mailman/message/36148493/]
* Change location of '''resource-path''' file to allow Python pip Wheels. eg: [https://github.com/sam-m888/gramps/commit/1bd29abfb6671db4e5d77b485eed21850728a05e#commitcomment-21095399 Running a post-install script is not possible with wheels, so it looks like we need another approach. I suggest that we look for the resources in the standard places at run-time. - Nick Hall] & [https://sourceforge.net/p/gramps/mailman/message/36029538/ Re: (Gramps-devel) tar files, zip files, distutils, etc.]
* {{bug|6300}}: '''Organize Tags be able to select a background color also for visability''' - [https://gramps-project.org/bugs/view.php?id=6300#c26888 This would be quite easy to do, but would require a database change. - Nick H]
* {{bug|10777}} Fulltext search on all elements, objects, items, types which can have a text / string in.
* Support Gedcom _UUID. Two choices 1) extend data model with a list of additional IDs, which would be _UUID or possibly GOVID, GEONamesID etc. 2) Store them in attributes. The former has advantage that they are invisible to users except for tools explicitly using them, also could easily support db lookup like GrampsID. The latter limits work to import/export. Gedcom L group has just completed a vote on how they should work for import/export. Ultimate goal, better merging.
[[Category:Developers/General]]
[[Category:Developers/Roadmap]]

Navigation menu