Gramps 4.2 Release schedule

classic Classic list List threaded Threaded
141 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

Gramps 4.2 Release schedule

DS Blank
Looks like there is a consensus forming on the following plan:

May 25 - May 31: finish up any new features and bug fixes.

June 1, one week from today: "string freeze" date. After June 1, there should be no changes to translations strings _("strings like this") and no new features added in code. (If someone would like to manage this release, please step up.)

New maintenance/gramps42 bug-fix-only branch is created; master will be called gramps50 (mostly for addons to match). addons will get a new directory, gramps50, and addons-source will get a new branch for maintenance/gramps42.

June 1 - June 15: translators try to get their languages close to 100% translated, and also test out code; developers only apply bug fixes to gramps42 branch and master. Everyone tests the new version. Addons that aren't ready should be marked UNSTABLE.

June 15: Release date. Packagers begin to build their downloadables. There is no immediate rush... some packagers might be unavailable for a week or two. When Mac and Windows downloads are available, we can advertise their availability.

June 15 - forward: Code waiting for the next version can begin to land in master. Because the ability to swap out backends is a conceptually big change (and fairly big code refactor) going to gramps50 seems warranted. New feature development begins.

Does that capture the general consensus?

-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: Gramps 4.2 Release schedule

John Ralls-2

> On May 25, 2015, at 5:45 AM, Doug Blank <[hidden email]> wrote:
>
> Looks like there is a consensus forming on the following plan:
>
> May 25 - May 31: finish up any new features and bug fixes.
>
> June 1, one week from today: "string freeze" date. After June 1, there should be no changes to translations strings _("strings like this") and no new features added in code. (If someone would like to manage this release, please step up.)
>
> New maintenance/gramps42 bug-fix-only branch is created; master will be called gramps50 (mostly for addons to match). addons will get a new directory, gramps50, and addons-source will get a new branch for maintenance/gramps42.
>
> June 1 - June 15: translators try to get their languages close to 100% translated, and also test out code; developers only apply bug fixes to gramps42 branch and master. Everyone tests the new version. Addons that aren't ready should be marked UNSTABLE.
>
> June 15: Release date. Packagers begin to build their downloadables. There is no immediate rush... some packagers might be unavailable for a week or two. When Mac and Windows downloads are available, we can advertise their availability.
>
> June 15 - forward: Code waiting for the next version can begin to land in master. Because the ability to swap out backends is a conceptually big change (and fairly big code refactor) going to gramps50 seems warranted. New feature development begins.
>
> Does that capture the general consensus?

Doug,

It’s fine with me.

 I’m glad you’re planning to hold back your DB backend separation for the next release, it’s clearly something that warrants extensive testing.  To that end, perhaps we should consider packaging an “alpha” release (tarballs and AIOs) early next year. We'd need to figure out how to keep SourceForge from pointing the Big Green Button at it.

Regards,
John Ralls



------------------------------------------------------------------------------
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 : Gramps 4.2 Release schedule

jerome
In reply to this post by DS Blank
Fine for me, too.

Should we not move or add some bug reports on current roadmap[1]
into mantis?

[1] https://gramps-project.org/bugs/roadmap_page.php?version_id=53


Jérôme

--------------------------------------------
En date de : Lun 25.5.15, Doug Blank <[hidden email]> a écrit :

 Objet: [Gramps-devel] Gramps 4.2 Release schedule
 À: "Gramps Development List" <[hidden email]>
 Date: Lundi 25 mai 2015, 14h45
 
 Looks like there is a
 consensus forming on the following plan:
 May 25 - May 31: finish up any new features and
 bug fixes.
 June 1, one week from today: "string
 freeze" date. After June 1, there should be no changes
 to translations strings _("strings like this") and
 no new features added in code. (If someone would like to
 manage this release, please step up.)
 New maintenance/gramps42 bug-fix-only branch is
 created; master will be called gramps50 (mostly for addons
 to match). addons will get a new directory, gramps50, and
 addons-source will get a new branch for
 maintenance/gramps42.
 June 1 - June 15: translators try to get their
 languages close to 100% translated, and also test out code;
 developers only apply bug fixes to gramps42 branch and
 master. Everyone tests the new version. Addons that
 aren't ready should be marked UNSTABLE.
 June 15: Release date. Packagers begin to build
 their downloadables. There is no immediate rush... some
 packagers might be unavailable for a week or two. When Mac
 and Windows downloads are available, we can advertise their
 availability.
 June 15 - forward: Code waiting for the next
 version can begin to land in master. Because the ability to
 swap out backends is a conceptually big change (and fairly
 big code refactor) going to gramps50 seems warranted. New
 feature development begins.
 Does that capture the general
 consensus?
 -Doug
 -----La pièce jointe associée suit-----
 
 ------------------------------------------------------------------------------
 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
 -----La pièce jointe associée suit-----
 
 _______________________________________________
 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: Re : Gramps 4.2 Release schedule

enno
Jerome,
> Fine for me, too.
>
> Should we not move or add some bug reports on current roadmap[1]
> into mantis?
>
> [1] https://gramps-project.org/bugs/roadmap_page.php?version_id=53
Move as in move away? The list looks quite large to me, and I'm not very
good with 4.2 code yet.

And at the same time, if this is going to be 5.0, I'd really like to
have this one solved:

https://gramps-project.org/bugs/view.php?id=8377

This is the main reason why I'm still using 3.4, because I can't get
used to that scrolling. Adapting to the new place hierarchy will
probably be easier.

regards,

Enno


------------------------------------------------------------------------------
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: Re : Gramps 4.2 Release schedule

DS Blank
On Tue, May 26, 2015 at 7:36 AM, Enno Borgsteede <[hidden email]> wrote:
Jerome,
> Fine for me, too.
>
> Should we not move or add some bug reports on current roadmap[1]
> into mantis?
>
> [1] https://gramps-project.org/bugs/roadmap_page.php?version_id=53
Move as in move away? The list looks quite large to me, and I'm not very
good with 4.2 code yet.

And at the same time, if this is going to be 5.0, I'd really like to
have this one solved:

https://gramps-project.org/bugs/view.php?id=8377

This is the main reason why I'm still using 3.4, because I can't get
used to that scrolling. Adapting to the new place hierarchy will
probably be easier.

Does your patch there work well for you? Should we apply that to Gramps 4.2?

The only other blocker looks to be the GEDCOM place importing issue, which appears to be a regression to an attempted fix:


Anything else considered a block for release?

-Doug

 

regards,

Enno


------------------------------------------------------------------------------
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: Re : Gramps 4.2 Release schedule

enno
Doug,
On Tue, May 26, 2015 at 7:36 AM, Enno Borgsteede <[hidden email]> wrote:
Jerome,
> Fine for me, too.
>
> Should we not move or add some bug reports on current roadmap[1]
> into mantis?
>
> [1] https://gramps-project.org/bugs/roadmap_page.php?version_id=53
Move as in move away? The list looks quite large to me, and I'm not very
good with 4.2 code yet.

And at the same time, if this is going to be 5.0, I'd really like to
have this one solved:

https://gramps-project.org/bugs/view.php?id=8377

This is the main reason why I'm still using 3.4, because I can't get
used to that scrolling. Adapting to the new place hierarchy will
probably be easier.

Does your patch there work well for you? Should we apply that to Gramps 4.2?
No. It's a piece of dirty code, designed to 'block' GUI callbacks that slow down scrolling, and for that part it works well. It 'blocks' those callbacks from eating CPU cycles by using empty callback functions, where for some we may actually need code when a user does more than looking at the (person) tree.

With this patch, deleting persons, or changing their surnames, so that they need to be shown somewhere elsewhere in the tree, is not 100 % reliable, and I managed to mess up my test database, by doing a couple of deletes in a row. That can probably be cured by adding some code to intercept the callbacks that we really need to process, but on the long term, I think it's much cleaner to switch to Gtk objects as prototyped by Nick. His prototypes scroll fast, but the views take longer to load, and a solution for that probably requires some extra discussion here.


The only other blocker looks to be the GEDCOM place importing issue, which appears to be a regression to an attempted fix:


I triggered that one with #8322, and Tim wrote that he needed more time to find a better solution for 4.1 and beyond. It's a bit nasty, because I think that in master some address code has been removed, and there are quite different ways between the use of ADDR in RootsMagic and Gramps itself. Tim's strategy looks good to me, and I'm prepared to help testing. Hope that helps.

regards,

Enno


------------------------------------------------------------------------------
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: Re : Gramps 4.2 Release schedule

DS Blank
On Tue, May 26, 2015 at 9:49 AM, Enno Borgsteede <[hidden email]> wrote:
Doug,
On Tue, May 26, 2015 at 7:36 AM, Enno Borgsteede <[hidden email]> wrote:
Jerome,
> Fine for me, too.
>
> Should we not move or add some bug reports on current roadmap[1]
> into mantis?
>
> [1] https://gramps-project.org/bugs/roadmap_page.php?version_id=53
Move as in move away? The list looks quite large to me, and I'm not very
good with 4.2 code yet.

And at the same time, if this is going to be 5.0, I'd really like to
have this one solved:

https://gramps-project.org/bugs/view.php?id=8377

This is the main reason why I'm still using 3.4, because I can't get
used to that scrolling. Adapting to the new place hierarchy will
probably be easier.

Does your patch there work well for you? Should we apply that to Gramps 4.2?
No. It's a piece of dirty code, designed to 'block' GUI callbacks that slow down scrolling, and for that part it works well. It 'blocks' those callbacks from eating CPU cycles by using empty callback functions, where for some we may actually need code when a user does more than looking at the (person) tree.

With this patch, deleting persons, or changing their surnames, so that they need to be shown somewhere elsewhere in the tree, is not 100 % reliable, and I managed to mess up my test database, by doing a couple of deletes in a row. That can probably be cured by adding some code to intercept the callbacks that we really need to process, but on the long term, I think it's much cleaner to switch to Gtk objects as prototyped by Nick. His prototypes scroll fast, but the views take longer to load, and a solution for that probably requires some extra discussion here.

Ah, ok thanks for the explanation. I think the consensus on Nick's prototypes was good, except for the two-pane view, which made it impossible to select two objects that differed in the first pane. Nick, is any of that prototype going into Gramps 4.2? If not, how to solve the scrolling issue? Or wait until Gramps 5.0?
 



The only other blocker looks to be the GEDCOM place importing issue, which appears to be a regression to an attempted fix:


I triggered that one with #8322, and Tim wrote that he needed more time to find a better solution for 4.1 and beyond. It's a bit nasty, because I think that in master some address code has been removed, and there are quite different ways between the use of ADDR in RootsMagic and Gramps itself. Tim's strategy looks good to me, and I'm prepared to help testing. Hope that helps.

Ok, we'll wait for Tim to see what the projected timeline is.

-Doug

regards,

Enno



------------------------------------------------------------------------------
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: Re : Gramps 4.2 Release schedule

Tim Lyons
Administrator
DS Blank wrote
On Tue, May 26, 2015 at 9:49 AM, Enno Borgsteede <[hidden email]> wrote:

>  The only other blocker looks to be the GEDCOM place importing issue,
> which appears to be a regression to an attempted fix:
>
>  https://gramps-project.org/bugs/view.php?id=8537
>
>    I triggered that one with #8322, and Tim wrote that he needed more
> time to find a better solution for 4.1 and beyond. It's a bit nasty,
> because I think that in master some address code has been removed, and
> there are quite different ways between the use of ADDR in RootsMagic and
> Gramps itself. Tim's strategy looks good to me, and I'm prepared to help
> testing. Hope that helps.
>

Ok, we'll wait for Tim to see what the projected timeline is.

I'm not going to be able to fix this by 1st June. I might be able to tackle it between 1 and 15 June, but (a) don't know whether there would be string changes, and (b) it might need a bit more testing, rather than being a quick fix before release.

By the way, as well as conforming to the GEDCOM spec, and taking account of the different structures in Gramps, I have also tried to conform to the recommendations in http://www.tamurajones.net/GEDCOMADDR.xhtml (see the extensive comment in libgedcom)! The particular (non-GEDCOM-standard) way in which some software uses the ADDR to refine the address which was provided by a PLAC may need to be dealt with by a GedcomExtension, but this should be OK once the basic structure is in place!

Sorry I can't provide a quick fix, but I don't have any more time available this week.

Tim.
Reply | Threaded
Open this post in threaded view
|

Re : Gramps 4.2 Release schedule

jerome
In reply to this post by DS Blank
Should we include translation strings for debug tools (or experimental one like phpgedviewer)

Currently, descriptions are in english into plugins manager
     gramps/plugins/tool/toolsdebug.gpr.py
but they have been included into translation template (POTFILES.in, gramps.pot).

We could skip them (keep debug tools in english only),
either by removing the translation marker, or put them
back to POTFILES.skip; or do you think that these tools
should be translated too?



--------------------------------------------
En date de : Lun 25.5.15, Doug Blank <[hidden email]> a écrit :

 Objet: [Gramps-devel] Gramps 4.2 Release schedule
 À: "Gramps Development List" <[hidden email]>
 Date: Lundi 25 mai 2015, 12h45
 
 Looks like there is a
 consensus forming on the following plan:
 May 25 - May 31: finish up any new features and
 bug fixes.
 June 1, one week from today: "string
 freeze" date. After June 1, there should be no changes
 to translations strings _("strings like this") and
 no new features added in code. (If someone would like to
 manage this release, please step up.)
 New maintenance/gramps42 bug-fix-only branch is
 created; master will be called gramps50 (mostly for addons
 to match). addons will get a new directory, gramps50, and
 addons-source will get a new branch for
 maintenance/gramps42.
 June 1 - June 15: translators try to get their
 languages close to 100% translated, and also test out code;
 developers only apply bug fixes to gramps42 branch and
 master. Everyone tests the new version. Addons that
 aren't ready should be marked UNSTABLE.
 June 15: Release date. Packagers begin to build
 their downloadables. There is no immediate rush... some
 packagers might be unavailable for a week or two. When Mac
 and Windows downloads are available, we can advertise their
 availability.
 June 15 - forward: Code waiting for the next
 version can begin to land in master. Because the ability to
 swap out backends is a conceptually big change (and fairly
 big code refactor) going to gramps50 seems warranted. New
 feature development begins.
 Does that capture the general
 consensus?
 -Doug
 -----La pièce jointe associée suit-----
 
 ------------------------------------------------------------------------------
 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
 -----La pièce jointe associée suit-----
 
 _______________________________________________
 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: Re : Gramps 4.2 Release schedule

enno
In reply to this post by Tim Lyons
Tim,
> I'm not going to be able to fix this by 1st June. I might be able to tackle
> it between 1 and 15 June, but (a) don't know whether there would be string
> changes, and (b) it might need a bit more testing, rather than being a quick
> fix before release.
I tried the quick fix by Jerome, just to avoid crashes, and noticed that
the addresses are all stored in alternative locations, just like they
are in 3.4, where it works for me. In 4.1 and beyond, they are however
deprecated, and they can't be added from the GUI anymore.

When imported locations have addresses, the alternate location tab is
visible, but only then. In other words, in 4.1 and 4,2 we now have an
inconsistency in so far, that a GEDCOM import can add data that no
regular user can.

I have not tested how a 3.4 database with alternative locations is
upgraded to 4.1. or 4.2, but since they have the same structure as main
locations in the 3.4 database, meaning street and other fields, I think
that they should be converted in the same way, i.e. to a hierarchy, so
that addresses can be removed from the location object a.s.a.p.
> By the way, as well as conforming to the GEDCOM spec, and taking account of
> the different structures in Gramps, I have also tried to conform to the
> recommendations in http://www.tamurajones.net/GEDCOMADDR.xhtml (see the
> extensive comment in libgedcom)! The particular (non-GEDCOM-standard) way in
> which some software uses the ADDR to refine the address which was provided
> by a PLAC may need to be dealt with by a GedcomExtension, but this should be
> OK once the basic structure is in place!
Well, if we agree that the ADDR record really has no place in the new
locations table, because it never had, not even in Gramps 3.4, I see no
reason for much special treatment either. To my knowledge, the only
software in the wild that writes ADDR records is RootsMagic, and that
software does not do what Tamura writes about the subject. That means
that in practical situations, we will never see anything else than the
RootsMagic format, where ADDR is a single line, designating an object or
a street address inside the town specified in PLAC, and where it can
therefore be imported as if it is embedded by the location specified in
the PLAC tag. That is the only real world use case that I know.

There is another case, and that's GEDCOM files created by Gramps itself.
They have ADDR tags in events when main location fields are filled, and
I think that is wrong. A place with fields is not a mailing address, and
should therefore not be exported as such. Locations should be exported
as a PLAC tag with an optional FORM structure, and nothing else. ADDR
structures should be reserved for those objects where formatted mailing
addresses really exist, which is nowhere in Gramps. The location fields
that I can see in the address tab for repositories do not follow GEDCOM
standard, since they do not support formatted lines like they should.
With formatted lines, I mean lines where I can type something like "1076
AD Amsterdam" as it should appear in a local mailing address.
> Sorry I can't provide a quick fix, but I don't have any more time available
> this week.
I understand that, but if you agree with the above, I think it's better
to use the quick fix anyway, because addresses never really worked in
Gramps.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re : Gramps 4.2 Release schedule

Nick Hall
On 27/05/15 21:30, Enno Borgsteede wrote:
> I tried the quick fix by Jerome, just to avoid crashes, and noticed that
> the addresses are all stored in alternative locations, just like they
> are in 3.4, where it works for me. In 4.1 and beyond, they are however
> deprecated, and they can't be added from the GUI anymore.

Correct.  Alternative locations are deprecated and should no longer be used.


Nick.


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re : Gramps 4.2 Release schedule

Nick Hall
In reply to this post by enno
On 27/05/15 21:30, Enno Borgsteede wrote:

> There is another case, and that's GEDCOM files created by Gramps itself.
> They have ADDR tags in events when main location fields are filled, and
> I think that is wrong. A place with fields is not a mailing address, and
> should therefore not be exported as such. Locations should be exported
> as a PLAC tag with an optional FORM structure, and nothing else. ADDR
> structures should be reserved for those objects where formatted mailing
> addresses really exist, which is nowhere in Gramps. The location fields
> that I can see in the address tab for repositories do not follow GEDCOM
> standard, since they do not support formatted lines like they should.
> With formatted lines, I mean lines where I can type something like "1076
> AD Amsterdam" as it should appear in a local mailing address.

It would be easy to get Gramps to export a place using PLAC and FORM tags.

Nick.


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re : Gramps 4.2 Release schedule

DS Blank
In reply to this post by enno
On Wed, May 27, 2015 at 4:30 PM, Enno Borgsteede <[hidden email]> wrote:
Tim,
> I'm not going to be able to fix this by 1st June. I might be able to tackle
> it between 1 and 15 June, but (a) don't know whether there would be string
> changes, and (b) it might need a bit more testing, rather than being a quick
> fix before release.
I tried the quick fix by Jerome, just to avoid crashes, and noticed that
the addresses are all stored in alternative locations, just like they
are in 3.4, where it works for me. In 4.1 and beyond, they are however
deprecated, and they can't be added from the GUI anymore.

When imported locations have addresses, the alternate location tab is
visible, but only then. In other words, in 4.1 and 4,2 we now have an
inconsistency in so far, that a GEDCOM import can add data that no
regular user can.

I have not tested how a 3.4 database with alternative locations is
upgraded to 4.1. or 4.2, but since they have the same structure as main
locations in the 3.4 database, meaning street and other fields, I think
that they should be converted in the same way, i.e. to a hierarchy, so
that addresses can be removed from the location object a.s.a.p.
> By the way, as well as conforming to the GEDCOM spec, and taking account of
> the different structures in Gramps, I have also tried to conform to the
> recommendations in http://www.tamurajones.net/GEDCOMADDR.xhtml (see the
> extensive comment in libgedcom)! The particular (non-GEDCOM-standard) way in
> which some software uses the ADDR to refine the address which was provided
> by a PLAC may need to be dealt with by a GedcomExtension, but this should be
> OK once the basic structure is in place!
Well, if we agree that the ADDR record really has no place in the new
locations table, because it never had, not even in Gramps 3.4, I see no
reason for much special treatment either. To my knowledge, the only
software in the wild that writes ADDR records is RootsMagic, and that
software does not do what Tamura writes about the subject. That means
that in practical situations, we will never see anything else than the
RootsMagic format, where ADDR is a single line, designating an object or
a street address inside the town specified in PLAC, and where it can
therefore be imported as if it is embedded by the location specified in
the PLAC tag. That is the only real world use case that I know.

There is another case, and that's GEDCOM files created by Gramps itself.
They have ADDR tags in events when main location fields are filled, and
I think that is wrong. A place with fields is not a mailing address, and
should therefore not be exported as such. Locations should be exported
as a PLAC tag with an optional FORM structure, and nothing else. ADDR
structures should be reserved for those objects where formatted mailing
addresses really exist, which is nowhere in Gramps. The location fields
that I can see in the address tab for repositories do not follow GEDCOM
standard, since they do not support formatted lines like they should.
With formatted lines, I mean lines where I can type something like "1076
AD Amsterdam" as it should appear in a local mailing address.
> Sorry I can't provide a quick fix, but I don't have any more time available
> this week.
I understand that, but if you agree with the above, I think it's better
to use the quick fix anyway, because addresses never really worked in
Gramps.

From what I understand, I agree that the quick fix is better than nothing. It at least allows the GEDOM to be imported, even if it loses such places. And we can apply better fixes as they are developed.

-Doug
 

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re : Gramps 4.2 Release schedule

enno
In reply to this post by Nick Hall
Nick,
> On 27/05/15 21:30, Enno Borgsteede wrote:
>> I tried the quick fix by Jerome, just to avoid crashes, and noticed that
>> the addresses are all stored in alternative locations, just like they
>> are in 3.4, where it works for me. In 4.1 and beyond, they are however
>> deprecated, and they can't be added from the GUI anymore.
> Correct.  Alternative locations are deprecated and should no longer be used.
OK, thanks. Are there any plans to take them out altogether?

I have yet to check what a schema upgrade does when alternative
locations are used, but since main and alternative locations are pretty
much the same in 3.4, I hope that they convert the same too.

My view for 4.2 is that when

PLAC Amsterdam, Noord Holland, Nederland
ADDR Nieuwe Kerk

is encountered, the ADDR content is interpreted as being contained in
PLAC, which means that the result will be a fully qualified PLAC like
Nieuwe Kerk, Amsterdam, Noord Holland, Nederland.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re : Gramps 4.2 Release schedule

Nick Hall
On 28/05/15 19:19, Enno Borgsteede wrote:
>> Correct.  Alternative locations are deprecated and should no longer be used.
> OK, thanks. Are there any plans to take them out altogether?

Not at the moment, but they will probably be removed in a future version.


>
> I have yet to check what a schema upgrade does when alternative
> locations are used, but since main and alternative locations are pretty
> much the same in 3.4, I hope that they convert the same too.

Alternative locations are not converted during the upgrade.  The
conversion would depend on how the user stores data in these locations.  
For example, suppose we have a main location:

Country = A, County = B, City = C

and an alternative location:

Country = A, County = D, City = C

Is D an alternative name for B?  Perhaps D is a new county and there has
been a boundary change?  We don't really know, so the conversion of
alternative locations is left to the user.

Does anyone actually use them anyway?  They aren't very useful.


>
> My view for 4.2 is that when
>
> PLAC Amsterdam, Noord Holland, Nederland
> ADDR Nieuwe Kerk
>
> is encountered, the ADDR content is interpreted as being contained in
> PLAC, which means that the result will be a fully qualified PLAC like
> Nieuwe Kerk, Amsterdam, Noord Holland, Nederland.

That seems reasonable.  A hierarchy of four places would be created.

We could use the FORM tag to record the place types:

PLAC Nieuwe Kerk, Amsterdam, Noord Holland, Nederland
FORM Church, City, Region, Country


Nick.


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re : Gramps 4.2 Release schedule

Nick Hall
In reply to this post by DS Blank
On 26/05/15 15:14, Doug Blank wrote:
I think it's much cleaner to switch to Gtk objects as prototyped by Nick. His prototypes scroll fast, but the views take longer to load, and a solution for that probably requires some extra discussion here.

Ah, ok thanks for the explanation. I think the consensus on Nick's prototypes was good, except for the two-pane view, which made it impossible to select two objects that differed in the first pane. Nick, is any of that prototype going into Gramps 4.2? If not, how to solve the scrolling issue? Or wait until Gramps 5.0?

The models are also used in the selectors where the slow load times are unacceptable.

I am considering using the new model for the place tree view as a fix to the following bug:

7943: Place tree view: show every hierarchy possibility
https://gramps-project.org/bugs/view.php?id=7943

We really need to display the same object more than once in a tree view.  This is not possible using the old model.


Nick.


------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Gramps 4.2 Release schedule

DS Blank
In reply to this post by DS Blank
Update:

gramps-project/addons-source has now been tagged/branched with a tag "gramps-4.2" and branch "maintenance/gramps42".

Planning on gramps-project/gramps tagging and branching in just a few hours... keep an eye out for the change. After that point, you should make fixes/translations to both gramps42 and master.

-Doug


On Mon, May 25, 2015 at 8:45 AM, Doug Blank <[hidden email]> wrote:
Looks like there is a consensus forming on the following plan:

May 25 - May 31: finish up any new features and bug fixes.

June 1, one week from today: "string freeze" date. After June 1, there should be no changes to translations strings _("strings like this") and no new features added in code. (If someone would like to manage this release, please step up.)

New maintenance/gramps42 bug-fix-only branch is created; master will be called gramps50 (mostly for addons to match). addons will get a new directory, gramps50, and addons-source will get a new branch for maintenance/gramps42.

June 1 - June 15: translators try to get their languages close to 100% translated, and also test out code; developers only apply bug fixes to gramps42 branch and master. Everyone tests the new version. Addons that aren't ready should be marked UNSTABLE.

June 15: Release date. Packagers begin to build their downloadables. There is no immediate rush... some packagers might be unavailable for a week or two. When Mac and Windows downloads are available, we can advertise their availability.

June 15 - forward: Code waiting for the next version can begin to land in master. Because the ability to swap out backends is a conceptually big change (and fairly big code refactor) going to gramps50 seems warranted. New feature development begins.

Does that capture the general consensus?

-Doug


------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Gramps 4.2 Release schedule

jerome
Note, with Paul, we tried to make the "switch between branches"
easier for translators.

I merged some translation strings/files[1].

So, any contributions should be easier to merge and check
whatever branch.

[1] https://gramps-project.org/wiki/index.php?title=Translation_migration

--------------------------------------------
En date de : Lun 1.6.15, Doug Blank <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] Gramps 4.2 Release schedule
 À: "Gramps Development List" <[hidden email]>
 Date: Lundi 1 juin 2015, 14h53
 
 Update:
 gramps-project/addons-source has now
 been tagged/branched with a tag "gramps-4.2" and
 branch "maintenance/gramps42".
 Planning on gramps-project/gramps
 tagging and branching in just a few hours... keep an eye out
 for the change. After that point, you should make
 fixes/translations to both gramps42 and
 master.
 -Doug
 
 On Mon, May 25, 2015 at
 8:45 AM, Doug Blank <[hidden email]>
 wrote:
 Looks like there is a consensus forming on the
 following plan:
 May 25 - May
 31: finish up any new features and bug fixes.
 June 1, one week from today:
 "string freeze" date. After June 1, there should
 be no changes to translations strings _("strings like
 this") and no new features added in code. (If someone
 would like to manage this release, please step
 up.)
 New
 maintenance/gramps42 bug-fix-only branch is created; master
 will be called gramps50 (mostly for addons to match). addons
 will get a new directory, gramps50, and addons-source will
 get a new branch for maintenance/gramps42.
 June 1 - June 15: translators try to
 get their languages close to 100% translated, and also test
 out code; developers only apply bug fixes to gramps42 branch
 and master. Everyone tests the new version. Addons that
 aren't ready should be marked UNSTABLE.
 June 15: Release date. Packagers
 begin to build their downloadables. There is no immediate
 rush... some packagers might be unavailable for a week or
 two. When Mac and Windows downloads are available, we can
 advertise their availability.
 June 15 - forward: Code waiting for
 the next version can begin to land in master. Because the
 ability to swap out backends is a conceptually big change
 (and fairly big code refactor) going to gramps50 seems
 warranted. New feature development begins.
 Does that capture the general
 consensus?
 -Doug
 
 
 -----La pièce jointe associée suit-----
 
 ------------------------------------------------------------------------------
 
 -----La pièce jointe associée suit-----
 
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
 

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Git Workflow

John Ralls-2
In reply to this post by DS Blank

> On Jun 1, 2015, at 7:53 AM, Doug Blank <[hidden email]> wrote:
>
> Planning on gramps-project/gramps tagging and branching in just a few hours... keep an eye out for the change. After that point, you should make fixes/translations to both gramps42 and master.

This seems like a good opportunity to suggest a change to our workflow: Let’s do all maintenance work exclusively in maintenance/gramps42 and periodically merge it with master. We’ve been using this method in GnuCash for the current development cycle and it has worked well so far; we’ve made it a bit easier on ourselves by calling the maintenance branch “maint”; we’ll rename it to its version number when we branch the next major release.

The big advantage is that one doesn’t have to remember to cherry-pick bug fixes as long as one makes the fix in the maintenance/gramps42 branch, everything gets swept into master by the periodic merges.

Regards,
John Ralls



------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Git Workflow

DS Blank
On Mon, Jun 1, 2015 at 12:13 PM, John Ralls <[hidden email]> wrote:

> On Jun 1, 2015, at 7:53 AM, Doug Blank <[hidden email]> wrote:
>
> Planning on gramps-project/gramps tagging and branching in just a few hours... keep an eye out for the change. After that point, you should make fixes/translations to both gramps42 and master.

This seems like a good opportunity to suggest a change to our workflow: Let’s do all maintenance work exclusively in maintenance/gramps42 and periodically merge it with master. We’ve been using this method in GnuCash for the current development cycle and it has worked well so far; we’ve made it a bit easier on ourselves by calling the maintenance branch “maint”; we’ll rename it to its version number when we branch the next major release.

The big advantage is that one doesn’t have to remember to cherry-pick bug fixes as long as one makes the fix in the maintenance/gramps42 branch, everything gets swept into master by the periodic merges.

This sounds reasonable. Can you provide some more details on this workflow? How do you merge only the changes that you want? Are there both "maint" and "maintenance/gramps42" branches?

-Doug

 

Regards,
John Ralls




------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
1234 ... 8