Re: [Gramps-devel] Roadmap for v5.1

[Paul C. <pau...@gm...>]

>
> For the v5.1 roadmap:
>

> What schedule should we aim for?  Do we want to go back to yearly major
> releases?
>
I think we should make an effort to release more often, 5.0.0 took way too
long.  Yearly would be good.

>
> Are there any policy changes we wish to make?
>

I think we should consider trying to organize our repo branches so that
developers don't need to make the same changes to multiple branches. If we
could set up procedures so that actual bugs are only made to one branch and
merged to others periodically, or something, it would cut down on work and
errors.  At the moment, the addons-source master branch is quite a bit
behind gramps50 and it is not clear how to correct this.  This might have
been easier if we had waited in changing the gramps repo master version
numbers until an API change made the gramps50 addons not work.  Which
hasn't happened yet.  We could have delayed creating the master
addons-source branch and its maintenance requirements until that point.

I am uncomfortable with having a single person with effectively absolute
veto power over changes, and who doesn't always follow the rules set up for
everyone.  I would prefer for some sort of voting process for significant
changes (count the thumbs up/down in PRs?).  And always use PRs for
significant changes, with at least a week or so to review before the
submitter accepts it himself, if that is even allowed.

>
> Would any changes to the requirements, such as dependencies or versions,
> be beneficial?
>
> We should try to make a list of the major and minor goals for the
> release.  What are you planning to work on?  Do any of the goals involve
> changes to the data model?
>

GEPS043, support for Gedcom EL place extensions has a PR already, but could
use some changes to data model to make it work better.
* 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 (Should use dated attribute IMO) (current PR uses notes).
* allow places to have attributes (for above)

There have been some requests for Notes to have citations and attributes.
Particularly for Persons and Families.

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).  More recent
versions of Gedcom allow this.  Dated attribute would help, or just make
these into Event/Fact types.

Notes currently allow xrefs to other objects, but these are not tracked as
db references and can become stale.  This has other side effects if
referenced objects are otherwise unused; they can get deleted in the
"Remove unused objects" tool.

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 db itself, something like the
'Researcher'/'Database owner' but including other data.

Paul C.