Roadmap for v5.1

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Roadmap for v5.1

Nick Hall
Devs,

Now that v5.0 is near to release, we can finally start to think about
the future.

For the v5.1 roadmap:

What schedule should we aim for?  Do we want to go back to yearly major
releases?

Are there any policy changes we wish to make?

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?

There is no hurry, but it is probably time to start the discussion.

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for v5.1

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for v5.1

Nick Hall
Paul,

Thanks for your reply.  I have incorporated your comments into a draft roadmap:

https://gramps-project.org/wiki/index.php?title=5.1_Roadmap

It would probably be best to discuss these topics in separate threads on the mailing list.

I didn't fully understand a few of your goals:

* Some 'attributes' we have currently don't match up well with Gedcom
* A method to mark objects as 'used'
* A way to attach objects to the db itself

Examples would be helpful.

Regards,


Nick.


On 24/03/18 14:26, Paul Culley wrote:
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.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for v5.1

dave.khuon@gmail.com
In reply to this post by Nick Hall
I wish we open up the development environment to Microsoft Visual Studio which is great for interactive debugging.

The stumbling blocks seem to be related to Gtk  (pygobject:is perhaps one of them).  I wish to learn a little more how the build team implement the all-in-one (AIO) to circumvent these issues at runtime, and how to apply it to resolve the dependency for development environment in Windows, and perhaps to create a project file (s ?) for gramps.

Another area that I think gramps in Windows is lacking is support for touch screen (2 in 1 devices).  Maybe newer features in Gtk or others(?) are already there (?)  I really don't know what I am talking about, except that  would be nice for modern laptops.

Thanks,
Dave

On Fri, Mar 23, 2018, 12:58 PM Nick Hall <[hidden email]> wrote:
Devs,

Now that v5.0 is near to release, we can finally start to think about
the future.

For the v5.1 roadmap:

What schedule should we aim for?  Do we want to go back to yearly major
releases?

Are there any policy changes we wish to make?

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?

There is no hurry, but it is probably time to start the discussion.

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for v5.1

Nick Hall
On 24/03/18 19:04, Dave Khuon wrote:

> I wish we open up the development environment to Microsoft Visual
> Studio which is great for interactive debugging.
>
> The stumbling blocks seem to be related to Gtk (pygobject:is perhaps
> one of them).  I wish to learn a little more how the build team
> implement the all-in-one (AIO) to circumvent these issues at runtime,
> and how to apply it to resolve the dependency for development
> environment in Windows, and perhaps to create a project file (s ?) for
> gramps.
>

See:

https://gramps-project.org/wiki/index.php?title=Gramps_for_Windows_with_MSYS2

> Another area that I think gramps in Windows is lacking is support for
> touch screen (2 in 1 devices).  Maybe newer features in Gtk or
> others(?) are already there (?)  I really don't know what I am talking
> about, except that  would be nice for modern laptops.
>
Gtk3 supports touch events and gestures.  What changes do we need to
make, if any, to support touch screens?

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel