From: Tim L. <guy...@gm...> - 2011-11-27 21:09:07
|
I now believe that the GEPS023 branch is ready to merge into trunk, and would ask that the core developers could test it and agree that it is ready for the move. There are a few known issues which are documented in the wiki: http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Known_Issues The issues include a few imports/exports (CSV, GeneWeb, ProGen, FTree, Grdb), simple report support, some webapp modules, and tool/Check. However, I do not believe that these issues should prevent merge into trunk. Jérôme has kindly offered to do GeneWeb, Doug has kindly offered to do webapp/*. I can do CSV, Simple* and the rest of tool/ Check. There are also a few minor changes and choices about the optimum default views. Obviously I would like to complete the merge as soon as possible to avoid extra work with merging changes to trunk into the change. This will also give more time for testing the change before the next release. I would like to thank Nick Hall for the enormous help and encouragement I have received from him, especially in implementing the tree model for two different primary objects which is largely his code. Also thanks for help from Michiel Nauta (upgrade transactions), John Ralls (make files), Jerome Rapinat (translation files etc.), Rob Healey, Gary Burton, Doug Blank and Cedric Scott and everyone else whose names I may have missed (all these people helped in testing and encouraged me in many ways apart from the specific items mentioned). Tim. |
From: jerome <rom...@ya...> - 2011-11-28 11:19:46
|
Hi, About GeneWeb file format, which does not support citation (volume/page, date, etc ...), how can I simply add a source to person, family and event objects? To replace code used by source reference is not enough! I am able to generate the source/citation link, but to use something like: person.add_citation(citation) does not work :( I guess it is because I already commited citation objects through the DB: citation = gen.lib.Citation() citation.set_reference_handle(source.get_handle()) self.db.add_citation(citation, self.trans) self.db.commit_citation(citation, self.trans) but I see nothing like set_citation() related to event, person, family. So, how to properly add source (and/or empty citation) to others primary objects when citations/sources already exist? I suppose it was what source_ref did: no source_ref without source! Else, ImportGeneWeb.py might be rewritten: to generate citation only when we add it to an other object (DB), then to think on relation with the source (file on data). Thank you. Jérôme --- En date de : Dim 27.11.11, Tim Lyons <guy...@gm...> a écrit : > De: Tim Lyons <guy...@gm...> > Objet: [Gramps-devel] GEPS023 merge into trunk > À: "Gramps Development List" <gra...@li...> > Cc: "Brian Matherly" <pez...@ya...> > Date: Dimanche 27 novembre 2011, 22h08 > I now believe that the GEPS023 branch > is ready to merge into trunk, > and would ask that the core developers could test it and > agree that it > is ready for the move. > > > > There are a few known issues which are documented in the > wiki: > http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Known_Issues > > The issues include a few imports/exports (CSV, GeneWeb, > ProGen, FTree, > Grdb), simple report support, some webapp modules, and > tool/Check. > However, I do not believe that these issues should prevent > merge into > trunk. Jérôme has kindly offered to do GeneWeb, Doug has > kindly > offered to do webapp/*. I can do CSV, Simple* and the rest > of tool/ > Check. There are also a few minor changes and choices about > the > optimum default views. > > Obviously I would like to complete the merge as soon as > possible to > avoid extra work with merging changes to trunk into the > change. This > will also give more time for testing the change before the > next release. > > I would like to thank Nick Hall for the enormous help > and > encouragement I have received from him, especially in > implementing the > tree model for two different primary objects which is > largely his > code. Also thanks for help from Michiel Nauta (upgrade > transactions), > John Ralls (make files), Jerome Rapinat (translation files > etc.), Rob > Healey, Gary Burton, Doug Blank and Cedric Scott and > everyone else > whose names I may have missed (all these people helped in > testing and > encouraged me in many ways apart from the specific items > mentioned). > > Tim. > ------------------------------------------------------------------------------ > All the data continuously generated in your IT > infrastructure > contains a definitive record of customers, application > performance, > security threats, fraudulent activity, and more. Splunk > takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Rob H. <rob...@gm...> - 2011-11-28 11:57:36
|
Greetings: >From my minor testing this geps023 over the last two weeks or more, with my production database, I have NOT come across ANY crashes or problems... *I give it a BIG +* ... Of course, I understand that there are pieces that are not done yet... I also give NarrativeWeb a GO as I have been playing with it over the last day or so after Tim did its upgrade for Citations.... Sincerely yours, Rob G. Healey On Sun, Nov 27, 2011 at 1:08 PM, Tim Lyons <guy...@gm...> wrote: > I now believe that the GEPS023 branch is ready to merge into trunk, and > would ask that the core developers could test it and agree that it is ready > for the move. > > > > There are a few known issues which are documented in the wiki: > http://www.gramps-project.org/**wiki/index.php?title=GEPS_023:** > _Storing_data_from_large_**sources#Known_Issues<http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Known_Issues> > > The issues include a few imports/exports (CSV, GeneWeb, ProGen, FTree, > Grdb), simple report support, some webapp modules, and tool/Check. However, > I do not believe that these issues should prevent merge into trunk. Jérôme > has kindly offered to do GeneWeb, Doug has kindly offered to do webapp/*. I > can do CSV, Simple* and the rest of tool/Check. There are also a few minor > changes and choices about the optimum default views. > > Obviously I would like to complete the merge as soon as possible to avoid > extra work with merging changes to trunk into the change. This will also > give more time for testing the change before the next release. > > I would like to thank Nick Hall for the enormous help and encouragement I > have received from him, especially in implementing the tree model for two > different primary objects which is largely his code. Also thanks for help > from Michiel Nauta (upgrade transactions), John Ralls (make files), Jerome > Rapinat (translation files etc.), Rob Healey, Gary Burton, Doug Blank and > Cedric Scott and everyone else whose names I may have missed (all these > people helped in testing and encouraged me in many ways apart from the > specific items mentioned). > > Tim. -- Sincerely yours, Rob G. Healey -- Sincerely yours, Rob G. Healey |
From: Doug B. <dou...@gm...> - 2011-11-28 13:43:58
|
On Sun, Nov 27, 2011 at 4:08 PM, Tim Lyons <guy...@gm...> wrote: > I now believe that the GEPS023 branch is ready to merge into trunk, > and would ask that the core developers could test it and agree that it > is ready for the move. Benny and Brian, If we are going to merge GEPS023 into trunk, it would also be convenient to do this sooner rather than later so that those of us that have time over the winter break/holiday seasons will be able to update related code, and test. Tim, as part of this transition, it would be quite useful to have a brief summary of the changes to the database, and how data is mapped to the new structures. -Doug > > > There are a few known issues which are documented in the wiki: > http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Known_Issues > > The issues include a few imports/exports (CSV, GeneWeb, ProGen, FTree, > Grdb), simple report support, some webapp modules, and tool/Check. > However, I do not believe that these issues should prevent merge into > trunk. Jérôme has kindly offered to do GeneWeb, Doug has kindly > offered to do webapp/*. I can do CSV, Simple* and the rest of tool/ > Check. There are also a few minor changes and choices about the > optimum default views. > > Obviously I would like to complete the merge as soon as possible to > avoid extra work with merging changes to trunk into the change. This > will also give more time for testing the change before the next release. > > I would like to thank Nick Hall for the enormous help and > encouragement I have received from him, especially in implementing the > tree model for two different primary objects which is largely his > code. Also thanks for help from Michiel Nauta (upgrade transactions), > John Ralls (make files), Jerome Rapinat (translation files etc.), Rob > Healey, Gary Burton, Doug Blank and Cedric Scott and everyone else > whose names I may have missed (all these people helped in testing and > encouraged me in many ways apart from the specific items mentioned). > > Tim. > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Tim L. <guy...@gm...> - 2011-11-28 19:54:46
|
On 28 Nov 2011, at 14:19, Brian Matherly wrote: > Tim, > > >> I now believe that the GEPS023 branch is ready to merge into trunk, >> and would ask that the core developers could test it and agree that >> it is ready for the move. >> > > As long as there are no crashes, then I agree we should merge the > changes into trunk. I assume that the importers/exporters that are > not updated yet don't crash - they just don't support citations. If > we are crash free, then let's get the changes into trunk. If there > are crashes, let's work them out before we merge. I presume that you are talking about the 'core' Gramps build. There are some modules in the sourceforge trunk repository that do not appear to be used in the current Gramps. With that proviso: * Jerome has done GeneWeb, * the parts of the simple report that are used in 'core' work, * I can't update ImportProGen, because I don't have access to the application for testing and anyway should it be regarded as part of 'core'? * It is possible that there are some other parts of the core Gramps build that might fail because of citations. I have done the relevant searches of the code, and run through most of the functions during testing, but I cannot be sure that something else will not crop up. Hence the need for more exposure in trunk. webapp/*, ExportFtre, ImportGrdb and the rest of the simple access routines are either not used in the core, or not included in the core. Import/Export CSV will probably fail (python exception). So, I believe that if I update the CSV modules, I will have met your criteria, would that be agreeable? > If we are worried about the GEPS branch diverging from trunk, you > can merge trunk changes into the GEPS branch. In fact, if you expect > a lot of conflicts from the merge, I highly recommend that you first > merge all trunk changes into the GEPS branch. Then, merging into > trunk should have no conflicts. I have already done two merges of trunk into the GEPS branch (Rev 18405 and 18498), and of course there were a few conflicts, which I resolved. However, with things like reports etc being more volatile, there is a chance that future merges are not so readily resolvable. Hence I am keen to do the merge as soon as possible. > Keep up the good work, Thanks. |
From: Paul F. <pf....@gm...> - 2011-11-28 21:07:01
|
On 11/28/11, Tim Lyons <guy...@gm...> wrote: > * I can't update ImportProGen, because I don't have access to the > application for testing and anyway should it be regarded as part of > 'core'? I didn't know anything about the ProGen genealogy program either but I think if you read this bug you'll learn: http://www.gramps-project.org/bugs/view.php?id=5146 It says where to get it from, for instance, and how to do the import into gramps. (The bug is a long read.) I hope your work gets merged into trunk as soon as possible. Every time I patch trunk I think of you. 8-) |
From: Jérôme <rom...@ya...> - 2011-11-29 06:53:58
|
Hi, I was a little bit stucked by the new source/citation handling! For GeneWeb, I looked at libgedcom, but gedcom file format can fill some data on citation fields, GeneWeb cannot. Otherwise, export to GeneWeb ignore sources on person/family/events (3.2.x, 3.3.x), I kept this limitation for the citation support/migration. Sources import with this file format is full/complete! For this migration/support, Tim pointed out that method is modified: we do not set an object any more when we add a source, but add something like a relation with source.handle and commit it to the database. Maybe to add a pseudo set_source() somewhere into gen.lib, will make the code more 'direct'? Yes, it is indirectly related to set_citation_list(), but only gedcom file format provides data on citation (inherited by gedcom), ie. we need to generate an empty citation for adding source during import on some file formats. I guess this might be the same way on plugins (API, reports, tools, gramplets, views, simple access, etc ...) 'gen.lib.citation.py' is equivalent to current 'gen.lib.src.py' but maybe a quick access to something like this citation itself is maybe missing? Could be an enhancement for gen.lib: a way to fill citation_list with only one empty citation, then to fill/set previous source fields? Note, to merge some 'empty' citations, makes my data 'more compact'! ie. it is like cleaning all our empty sourceref (no data). This is great for users but also for our databases. :) Minor changes which could be also merged is maybe the focus set for some fields on Editors and minor improvements for accessibility (ATK objects, tooltips, shortcuts, etc ...), but very cosmetic on the 'merge into trunk' process. Thanks! Jérôme Tim Lyons a écrit : > On 28 Nov 2011, at 14:19, Brian Matherly wrote: > >> Tim, >> >> >>> I now believe that the GEPS023 branch is ready to merge into trunk, >>> and would ask that the core developers could test it and agree that >>> it is ready for the move. >>> >> As long as there are no crashes, then I agree we should merge the >> changes into trunk. I assume that the importers/exporters that are >> not updated yet don't crash - they just don't support citations. If >> we are crash free, then let's get the changes into trunk. If there >> are crashes, let's work them out before we merge. > > > > I presume that you are talking about the 'core' Gramps build. There > are some modules in the sourceforge trunk repository that do not > appear to be used in the current Gramps. With that proviso: > * Jerome has done GeneWeb, > * the parts of the simple report that are used in 'core' work, > * I can't update ImportProGen, because I don't have access to the > application for testing and anyway should it be regarded as part of > 'core'? > * It is possible that there are some other parts of the core Gramps > build that might fail because of citations. I have done the relevant > searches of the code, and run through most of the functions during > testing, but I cannot be sure that something else will not crop up. > Hence the need for more exposure in trunk. > > webapp/*, ExportFtre, ImportGrdb and the rest of the simple access > routines are either not used in the core, or not included in the core. > > > Import/Export CSV will probably fail (python exception). > > So, I believe that if I update the CSV modules, I will have met your > criteria, would that be agreeable? > > > >> If we are worried about the GEPS branch diverging from trunk, you >> can merge trunk changes into the GEPS branch. In fact, if you expect >> a lot of conflicts from the merge, I highly recommend that you first >> merge all trunk changes into the GEPS branch. Then, merging into >> trunk should have no conflicts. > > I have already done two merges of trunk into the GEPS branch (Rev > 18405 and 18498), and of course there were a few conflicts, which I > resolved. However, with things like reports etc being more volatile, > there is a chance that future merges are not so readily resolvable. > Hence I am keen to do the merge as soon as possible. > > >> Keep up the good work, > > Thanks. > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Brian M. <br...@gr...> - 2011-11-29 01:07:30
|
>>> I now believe that the GEPS023 branch is ready to merge into trunk, >>> and would ask that the core developers could test it and agree that >>> it is ready for the move. >>> >> As long as there are no crashes, then I agree we should merge the >> changes into trunk. I assume that the importers/exporters that are >> not updated yet don't crash - they just don't support citations. > If >> we are crash free, then let's get the changes into trunk. If there >> are crashes, let's work them out before we merge. > > I presume that you are talking about the 'core' Gramps build. There > are some modules in the sourceforge trunk repository that do not > appear to be used in the current Gramps. With that proviso: > * Jerome has done GeneWeb, > * the parts of the simple report that are used in 'core' work, > * I can't update ImportProGen, because I don't have access to the > application for testing and anyway should it be regarded as part of > 'core'? > * It is possible that there are some other parts of the core Gramps > build that might fail because of citations. I have done the relevant > searches of the code, and run through most of the functions during > testing, but I cannot be sure that something else will not crop up. > Hence the need for more exposure in trunk. > > webapp/*, ExportFtre, ImportGrdb and the rest of the simple access > routines are either not used in the core, or not included in the core. > > Import/Export CSV will probably fail (python exception). > > So, I believe that if I update the CSV modules, I will have met your > criteria, would that be agreeable? Absolutely. Full steam ahead! ~BM |
From: Rob H. <rob...@gm...> - 2011-11-29 02:28:36
|
Greetings Brian and Tim: I truly agree that it should happen now! I am willing to continue testing on my own and reporting problems to this list... I know that things are going well so far as I have been using Geps023 for two weeks or more now.... I will hold off any changes that I am working on inside of NarrativeWeb until you have merged geps023 into trunk.... Sincerely yours, Rob G. Healey On Mon, Nov 28, 2011 at 5:07 PM, Brian Matherly <br...@gr...>wrote: > >>> I now believe that the GEPS023 branch is ready to merge into trunk, > > >>> and would ask that the core developers could test it and agree that > >>> it is ready for the move. > >>> > >> As long as there are no crashes, then I agree we should merge the > >> changes into trunk. I assume that the importers/exporters that are > >> not updated yet don't crash - they just don't support citations. > > If > >> we are crash free, then let's get the changes into trunk. If there > >> are crashes, let's work them out before we merge. > > > > I presume that you are talking about the 'core' Gramps build. There > > are some modules in the sourceforge trunk repository that do not > > appear to be used in the current Gramps. With that proviso: > > * Jerome has done GeneWeb, > > * the parts of the simple report that are used in 'core' work, > > * I can't update ImportProGen, because I don't have access to the > > application for testing and anyway should it be regarded as part of > > 'core'? > > * It is possible that there are some other parts of the core Gramps > > build that might fail because of citations. I have done the relevant > > searches of the code, and run through most of the functions during > > testing, but I cannot be sure that something else will not crop up. > > Hence the need for more exposure in trunk. > > > > webapp/*, ExportFtre, ImportGrdb and the rest of the simple access > > routines are either not used in the core, or not included in the core. > > > > Import/Export CSV will probably fail (python exception). > > > > So, I believe that if I update the CSV modules, I will have met your > > criteria, would that be agreeable? > > Absolutely. Full steam ahead! > > ~BM > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Sincerely yours, Rob G. Healey |
From: Tim L. <guy...@gm...> - 2011-12-04 00:34:35
|
Brian Matherly wrote > >> So, I believe that if I update the CSV modules, I will have met your >> criteria, would that be agreeable? > > Absolutely. Full steam ahead! > I have converted Import and Export CSV, so I expect to be merging GEPS023 into trunk tomorrow. -- View this message in context: http://gramps.1791082.n4.nabble.com/GEPS023-merge-into-trunk-tp4113375p4155546.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |