Database backends

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Database backends

DS Blank
Gramps devs,

For the first time today, I edited data in the regular Gramps Gtk without bsddb. In fact, I used the Django backend from the webapp. It isn't nearly complete, but is a good proof-of-concept that we can use to see that switching between backends is not that far away.

Experiment
----------------

First, if you would like to try an experiment:

1) Make sure you have the latest master from github. You'll need Django and python-sqlite3, and simplejson.

2) Start up Gramps Gtk as normal, and open any database, as usual

3) On the Dashboard, add the Python Gramplet

4) First, we need to get an alternate database. There are two to choose from. Enter one of the following in the Python Gramplet:

from gramps.webapp.databases.database1 import database

OR

from gramps.webapp.databases.database2 import database

# These could be any kind of Django databases... postgresql, mysql, mssql, etc. In fact, they are both sqlite3 databases. Just for testing.

5) Adding data from the Gtk desktop app doesn't work yet, but let's just import some from any gramps-importable file. Enter the following into the Gramplet:

from gramps.webapp.reports import import_file
from gramps.cli.user import User as GUser

# Now, you can import, replace the filename with your own. Paste into Gramplet, all on one line:
 
import_file(database, "/home/dblank/gramps/master/example/gramps/data.gramps", GUser())

6) You only have to import the data once, of course. Now, change database. Enter the following into the Gramplet:

self.dbstate.change_database(database)

# Here, self is the Python Gramplet, exposed for our convenience. 

7) You can now use Gramps as normal... reports, all views, and gramplets should all generally work. Editing may not update the screen correctly. Currently, you can't change to a different Django database once you have used one... you'll need to restart Gramps.

Proposal
-------------

Ok, now to the beginning of a proposal. One can construct a database object that implements all of the required methods. We simply need to create an interface for constructing and returning the database object. 

Each database instance should be in its own directory, and we may want to keep some of the same files (name.txt, dbversion.txt) for a general interface that will work with nothing installed).

Of course, we will keep the bsddb, and that code will stay in gramps. So, the file that will construct a bsddb database will be fairly small. 

Some backends will need some user editing of settings. For example, one can use postgresql, mysql, or other systems, even remotely.

I would think one of the first backends would be a vanilla sqlite3, but only using it as a datastore (not relational data). Perhaps using the Sqlite Export format. But any datastore-type db should be fine. The DbDictionary could also be finished and would work as a nice test.

Perhaps the biggest question is: are we ready to start moving towards a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0 could have such an interface.

If there is interest, I can start a GEPS, so we can start to identify the issues, and make some decisions, if necessary.

-Doug

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

DS Blank
On Mon, May 11, 2015 at 1:51 PM, Doug Blank <[hidden email]> wrote:
Gramps devs,

For the first time today, I edited data in the regular Gramps Gtk without bsddb. In fact, I used the Django backend from the webapp. It isn't nearly complete, but is a good proof-of-concept that we can use to see that switching between backends is not that far away.

Experiment
----------------

First, if you would like to try an experiment:

1) Make sure you have the latest master from github. You'll need Django and python-sqlite3, and simplejson.

I forgot that you'll need to initialize the Django databases:

1a) cd gramps/webapp/

1b) make clean; make

You'll enter two passwords, twice each (admin passwords for the web interface---not needed now).
 

2) Start up Gramps Gtk as normal, and open any database, as usual

3) On the Dashboard, add the Python Gramplet

4) First, we need to get an alternate database. There are two to choose from. Enter one of the following in the Python Gramplet:

from gramps.webapp.databases.database1 import database

OR

from gramps.webapp.databases.database2 import database

# These could be any kind of Django databases... postgresql, mysql, mssql, etc. In fact, they are both sqlite3 databases. Just for testing.

5) Adding data from the Gtk desktop app doesn't work yet, but let's just import some from any gramps-importable file. Enter the following into the Gramplet:

from gramps.webapp.reports import import_file
from gramps.cli.user import User as GUser

# Now, you can import, replace the filename with your own. Paste into Gramplet, all on one line:
 
import_file(database, "/home/dblank/gramps/master/example/gramps/data.gramps", GUser())

6) You only have to import the data once, of course. Now, change database. Enter the following into the Gramplet:

self.dbstate.change_database(database)

# Here, self is the Python Gramplet, exposed for our convenience. 

7) You can now use Gramps as normal... reports, all views, and gramplets should all generally work. Editing may not update the screen correctly. Currently, you can't change to a different Django database once you have used one... you'll need to restart Gramps.

Proposal
-------------

Ok, now to the beginning of a proposal. One can construct a database object that implements all of the required methods. We simply need to create an interface for constructing and returning the database object. 

Each database instance should be in its own directory, and we may want to keep some of the same files (name.txt, dbversion.txt) for a general interface that will work with nothing installed).

Of course, we will keep the bsddb, and that code will stay in gramps. So, the file that will construct a bsddb database will be fairly small. 

Some backends will need some user editing of settings. For example, one can use postgresql, mysql, or other systems, even remotely.

I would think one of the first backends would be a vanilla sqlite3, but only using it as a datastore (not relational data). Perhaps using the Sqlite Export format. But any datastore-type db should be fine. The DbDictionary could also be finished and would work as a nice test.

Perhaps the biggest question is: are we ready to start moving towards a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0 could have such an interface.

If there is interest, I can start a GEPS, so we can start to identify the issues, and make some decisions, if necessary.

-Doug


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

Nick Hall
In reply to this post by DS Blank
On 11/05/15 18:51, Doug Blank wrote:
> Perhaps the biggest question is: are we ready to start moving towards
> a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0
> could have such an interface.
>

Good idea.  A vanilla sqllite3 backend should be more portable than
bsddb.  Other object stores or even a graph database backend might be
interesting.


> If there is interest, I can start a GEPS, so we can start to identify
> the issues, and make some decisions, if necessary.
>

Please start a GEPS.  The way we handle transactions will need some
thought.  At the moment import bsddb DbTxn objects directly where needed.

Nick.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

DS Blank
On Mon, May 11, 2015 at 3:01 PM, Nick Hall <[hidden email]> wrote:
On 11/05/15 18:51, Doug Blank wrote:
> Perhaps the biggest question is: are we ready to start moving towards
> a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0
> could have such an interface.
>

Good idea.  A vanilla sqllite3 backend should be more portable than
bsddb.  Other object stores or even a graph database backend might be
interesting.

Some of the no-sql projects would probably be a nice fit. I think the sqlite3 is good for its long term stability, and should be as fast as bsddb.
 


> If there is interest, I can start a GEPS, so we can start to identify
> the issues, and make some decisions, if necessary.
>

Please start a GEPS.  The way we handle transactions will need some
thought.  At the moment import bsddb DbTxn objects directly where needed.

Yes, indeed. In DbDjango, transactions in Python are just a facade. I think we can make them work with history/undo/redo... which I think would be the only real use for them. One should be able to get a Transaction from the database... as part of this, we can polish up the abstractions a bit.

BTW, I think that editing and adding Django objects now works from Gtk Gramps. Still some GUI/signals things to iron out...

-Doug
 

Nick.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

DS Blank
Updated GEPS 32: Database backend API:


As a first step, I created a Database plugin, and moved all of the BSDDB items to gramps.plugins.datasbase in bsddb.gpr.py. This is work in progress in the branch geps/gep-032-database-backend on the main gramps-project github.

Everything is working so far, but needs more testing. And, needs to be able to store the backend type in the directory, and select backend type on creation. BSDDB will remain the default, for those places where a db is created automatically. But it would be easy to make that a configurable thing.

I guess with Gramps 4.2 scheduled soon we should wait until after it is released? Or should we polish it off, and get gramps42 out there with the ability to explore new backends this next year?

-Doug


On Mon, May 11, 2015 at 5:25 PM, Doug Blank <[hidden email]> wrote:
On Mon, May 11, 2015 at 3:01 PM, Nick Hall <[hidden email]> wrote:
On 11/05/15 18:51, Doug Blank wrote:
> Perhaps the biggest question is: are we ready to start moving towards
> a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0
> could have such an interface.
>

Good idea.  A vanilla sqllite3 backend should be more portable than
bsddb.  Other object stores or even a graph database backend might be
interesting.

Some of the no-sql projects would probably be a nice fit. I think the sqlite3 is good for its long term stability, and should be as fast as bsddb.
 


> If there is interest, I can start a GEPS, so we can start to identify
> the issues, and make some decisions, if necessary.
>

Please start a GEPS.  The way we handle transactions will need some
thought.  At the moment import bsddb DbTxn objects directly where needed.

Yes, indeed. In DbDjango, transactions in Python are just a facade. I think we can make them work with history/undo/redo... which I think would be the only real use for them. One should be able to get a Transaction from the database... as part of this, we can polish up the abstractions a bit.

BTW, I think that editing and adding Django objects now works from Gtk Gramps. Still some GUI/signals things to iron out...

-Doug
 

Nick.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

Nick Hall
On 12/05/15 22:12, Doug Blank wrote:

> Everything is working so far, but needs more testing. And, needs to be
> able to store the backend type in the directory, and select backend
> type on creation. BSDDB will remain the default, for those places
> where a db is created automatically. But it would be easy to make that
> a configurable thing.
>
> I guess with Gramps 4.2 scheduled soon we should wait until after it
> is released? Or should we polish it off, and get gramps42 out there
> with the ability to explore new backends this next year?
>

I suggest that it should wait until after v4.2 is released.  Any
database changes like this will need rigorous testing.

Keep the code in a GEPS branch for now.

Nick.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

Serge Noiraud-2
In reply to this post by DS Blank
Le 12/05/2015 23:12, Doug Blank a écrit :
Updated GEPS 32: Database backend API:


As a first step, I created a Database plugin, and moved all of the BSDDB items to gramps.plugins.datasbase in bsddb.gpr.py. This is work in progress in the branch geps/gep-032-database-backend on the main gramps-project github.
Thanks.

Everything is working so far, but needs more testing. And, needs to be able to store the backend type in the directory, and select backend type on creation. BSDDB will remain the default, for those places where a db is created automatically. But it would be easy to make that a configurable thing.
Agree for that.

I guess with Gramps 4.2 scheduled soon we should wait until after it is released? Or should we polish it off, and get gramps42 out there with the ability to explore new backends this next year?

-Doug


On Mon, May 11, 2015 at 5:25 PM, Doug Blank <[hidden email]> wrote:
On Mon, May 11, 2015 at 3:01 PM, Nick Hall <[hidden email]> wrote:
On 11/05/15 18:51, Doug Blank wrote:
> Perhaps the biggest question is: are we ready to start moving towards
> a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0
> could have such an interface.
>

Good idea.  A vanilla sqllite3 backend should be more portable than
bsddb.  Other object stores or even a graph database backend might be
interesting.

Some of the no-sql projects would probably be a nice fit. I think the sqlite3 is good for its long term stability, and should be as fast as bsddb.
I hope it will be faster.

I'm actually trying to load the ITIS gedcom database with profiling to see where are the bottlenecks.
I started on 2014-10-24 and it's not finished. It's the third time I try this and I hope it will be the last one.
The gedcom contains more than 5 millions lines.

When it will be finished, I'll make a save of this and try to add comments on the wiki about these performances.

It took aproximately One day to load the surnames and persons and since 2014-10-25, gramps is making references and families.

I think It will be very useful to have the possibility to change the database backend.

 


> If there is interest, I can start a GEPS, so we can start to identify
> the issues, and make some decisions, if necessary.
>

Please start a GEPS.  The way we handle transactions will need some
thought.  At the moment import bsddb DbTxn objects directly where needed.

Yes, indeed. In DbDjango, transactions in Python are just a facade. I think we can make them work with history/undo/redo... which I think would be the only real use for them. One should be able to get a Transaction from the database... as part of this, we can polish up the abstractions a bit.

BTW, I think that editing and adding Django objects now works from Gtk Gramps. Still some GUI/signals things to iron out...

-Doug
 

Nick.
Serge

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

DS Blank
On Wed, May 13, 2015 at 3:45 AM, Serge Noiraud <[hidden email]> wrote:
Le 12/05/2015 23:12, Doug Blank a écrit :
Updated GEPS 32: Database backend API:


As a first step, I created a Database plugin, and moved all of the BSDDB items to gramps.plugins.datasbase in bsddb.gpr.py. This is work in progress in the branch geps/gep-032-database-backend on the main gramps-project github.
Thanks.

Everything is working so far, but needs more testing. And, needs to be able to store the backend type in the directory, and select backend type on creation. BSDDB will remain the default, for those places where a db is created automatically. But it would be easy to make that a configurable thing.
Agree for that.

I guess with Gramps 4.2 scheduled soon we should wait until after it is released? Or should we polish it off, and get gramps42 out there with the ability to explore new backends this next year?

-Doug


On Mon, May 11, 2015 at 5:25 PM, Doug Blank <[hidden email]> wrote:
On Mon, May 11, 2015 at 3:01 PM, Nick Hall <[hidden email]> wrote:
On 11/05/15 18:51, Doug Blank wrote:
> Perhaps the biggest question is: are we ready to start moving towards
> a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0
> could have such an interface.
>

Good idea.  A vanilla sqllite3 backend should be more portable than
bsddb.  Other object stores or even a graph database backend might be
interesting.

Some of the no-sql projects would probably be a nice fit. I think the sqlite3 is good for its long term stability, and should be as fast as bsddb.
I hope it will be faster.

I'm actually trying to load the ITIS gedcom database with profiling to see where are the bottlenecks.
I started on 2014-10-24 and it's not finished. It's the third time I try this and I hope it will be the last one.
The gedcom contains more than 5 millions lines.

Wow, that's amazing. I don't think the database layer is going to be the bottleneck... But I suspect that we have some linear searches in the import process. That can make some parts exponential. Different backends can help with that, as we can abstract those searches out and easily create new indices. That could really help.

-Doug
 

When it will be finished, I'll make a save of this and try to add comments on the wiki about these performances.

It took aproximately One day to load the surnames and persons and since 2014-10-25, gramps is making references and families.

I think It will be very useful to have the possibility to change the database backend.

 


> If there is interest, I can start a GEPS, so we can start to identify
> the issues, and make some decisions, if necessary.
>

Please start a GEPS.  The way we handle transactions will need some
thought.  At the moment import bsddb DbTxn objects directly where needed.

Yes, indeed. In DbDjango, transactions in Python are just a facade. I think we can make them work with history/undo/redo... which I think would be the only real use for them. One should be able to get a Transaction from the database... as part of this, we can polish up the abstractions a bit.

BTW, I think that editing and adding Django objects now works from Gtk Gramps. Still some GUI/signals things to iron out...

-Doug
 

Nick.
Serge

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database backends

DS Blank
In reply to this post by DS Blank
On Mon, May 11, 2015 at 1:55 PM, Doug Blank <[hidden email]> wrote:
On Mon, May 11, 2015 at 1:51 PM, Doug Blank <[hidden email]> wrote:
Gramps devs,

For the first time today, I edited data in the regular Gramps Gtk without bsddb. In fact, I used the Django backend from the webapp. It isn't nearly complete, but is a good proof-of-concept that we can use to see that switching between backends is not that far away.

Experiment
----------------

First, if you would like to try an experiment:

1) Make sure you have the latest master from github. You'll need Django and python-sqlite3, and simplejson.

I forgot that you'll need to initialize the Django databases:

1a) cd gramps/webapp/

1b) make clean; make

You'll enter two passwords, twice each (admin passwords for the web interface---not needed now).
 

2) Start up Gramps Gtk as normal, and open any database, as usual

3) On the Dashboard, add the Python Gramplet

4) First, we need to get an alternate database. There are two to choose from. Enter one of the following in the Python Gramplet:

from gramps.webapp.databases.database1 import database

OR

from gramps.webapp.databases.database2 import database

For those of you trying this at home in master, step #4 has changed. It is now:

from gramps.webapp.dbdjango import DbDjango
database = DbDjango("/home/dblank/gramps/master/gramps/webapp/databases/database1")

or

database = DbDjango("/home/dblank/gramps/master/gramps/webapp/databases/database2") 

(change your path to point to a directory with a default_settings.py Django file. Restart to switch django databases, for now)

This will be the last change made to trunk, as development has now switched to the git branch geps/gep-032-database-backend.

Development help needed; testing help needed soon.

-Doug

# These could be any kind of Django databases... postgresql, mysql, mssql, etc. In fact, they are both sqlite3 databases. Just for testing.

5) Adding data from the Gtk desktop app doesn't work yet, but let's just import some from any gramps-importable file. Enter the following into the Gramplet:

from gramps.webapp.reports import import_file
from gramps.cli.user import User as GUser

# Now, you can import, replace the filename with your own. Paste into Gramplet, all on one line:
 
import_file(database, "/home/dblank/gramps/master/example/gramps/data.gramps", GUser())

6) You only have to import the data once, of course. Now, change database. Enter the following into the Gramplet:

self.dbstate.change_database(database)

# Here, self is the Python Gramplet, exposed for our convenience. 

7) You can now use Gramps as normal... reports, all views, and gramplets should all generally work. Editing may not update the screen correctly. Currently, you can't change to a different Django database once you have used one... you'll need to restart Gramps.

Proposal
-------------

Ok, now to the beginning of a proposal. One can construct a database object that implements all of the required methods. We simply need to create an interface for constructing and returning the database object. 

Each database instance should be in its own directory, and we may want to keep some of the same files (name.txt, dbversion.txt) for a general interface that will work with nothing installed).

Of course, we will keep the bsddb, and that code will stay in gramps. So, the file that will construct a bsddb database will be fairly small. 

Some backends will need some user editing of settings. For example, one can use postgresql, mysql, or other systems, even remotely.

I would think one of the first backends would be a vanilla sqlite3, but only using it as a datastore (not relational data). Perhaps using the Sqlite Export format. But any datastore-type db should be fine. The DbDictionary could also be finished and would work as a nice test.

Perhaps the biggest question is: are we ready to start moving towards a decoupling of bsddb and Gramps Gtk? I'm thinking that a Gramps 5.0 could have such an interface.

If there is interest, I can start a GEPS, so we can start to identify the issues, and make some decisions, if necessary.

-Doug



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel