[Gramps-devel] gramps50 and 5.0.0

---------- Forwarded message ----------
From: Nick Hall <nick-***@gramps-project.org>
Date: Sat, 15 Oct 2016 17:15:07 +0100
Subject: Re: [Gramps-users] Gramps v5.0

When do you expect a stable version to be available for regular users?

The answer to that question is_always_ "When it's ready".
The dev team/may/ have a release schedule in mind, IDK.

We are currently reviewing the database code for 5.0 in detail.

I expect the next alpha release in a couple of weeks. Hopefully 5.0
will be released for regular users by the end of the year.

Nick.

Nick Hall

2017-04-17 13:23:04 UTC

Post by Paul Franklin
Speaking of gramps50, it's about that time of the year when
I start wondering about my annual question: is there any
schedule for when we'll release <the next gramps>, any
defined date?
If not, how about one?

Unfortunately, I don't have the time to devote for a release.

We need someone to volunteer to be the 5.0 release manager. This person
will need to co-ordinate fixing the remaining issues on the roadmap,
testing and the release schedule. They will need to do extensive testing
themselves to ensure quality.

Any volunteers?

Nick.

Paul Franklin

2017-04-25 01:27:12 UTC

Unfortunately, I don't have the time to devote for a release.
We need someone to volunteer to be the 5.0 release manager. This person
will need to co-ordinate fixing the remaining issues on the roadmap,
testing and the release schedule. They will need to do extensive testing
themselves to ensure quality.
Any volunteers?
Nick.

As near as I can tell, Nick seems to be taking what I can
only describe as an overkill or extreme position, evidently
thinking that because he is the czar these days that
anything which goes out must be thoroughly tested, ideally
by him personally.

If this was happening in the past I was unaware of it. I
don't think we have the people to do that and I especially
don't think that the czar should do that. Anybody in that
position usually does far more than any normal developer's
share already.

I thought -- and still think -- that testing should be done
by everybody, in the normal course of things. Users too.

As I recall we used to (somehow) point power users at trunk
and ask them to put it through its paces. Besides all
developers using it of course.

The release of 5.0.0 is months behind any possible schedule.
After all, 4.2.0 was released (late) in August 2015, over a
year and a half ago. I proposed late last year that we
should release the then-current master as 4.3.0, after
purging all the new-DB code. But Nick didn't want that,
saying that he felt that 5.0.0 could be released by the end
of 2016.

Well, I don't know what he plans on doing to master, if
anything. He talks about "issues on the roadmap" but from
what I remember of past release cycles more than once we
simply decided certain "issues" wouldn't be fixed at all,
even if they happened to be on the roadmap.

I think we ought to declare the current "master" as "done"
or "good enough" or whatever, and branch off a maintenance
gramps from it. Maybe "ready for testing"?

He talked about a "release manager" but as far as I am
concerned that used to be -- and still is, assuming he is
willing -- Jerome. But I think a "release manager" is what
Steve Charette used to be, the person who takes the current
state of some repo tree and makes a tar file from it, then
uploads it.

In my mind a "release manager" has nothing to do with
personally checking every line of code in gramps, or
whatever Nick is thinking of.

We are woefully understaffed and we shouldn't think we can
continue as before. Our users will find any bugs. They
always have and they always will. Some of us will then try
to fix them.

Anything made by humans can never be perfect.

So since nobody has volunteered (publicly) in response to
Nick's query, here is what I explicitly propose.

I will personally take over the responsibility of seeing
that the <next gramps> is released.

But I will only do it if everybody agrees to my conditions,
or qualifications, or whatever you care to call them.

One is that I will have the final decision-making authority
as to what that <next gramps> will contain.

For instance I plan to entirely remove, or at least comment
out, all the new-DB code, wherever it is. And I do not mean
allowing it to "hide" behind a __debug_ flag as is presently
the case. This removal or elimination will happen in the
maintenance branch that "master" will become. The "master"
branch/repo will remain as it is now -- with all the new-DB
code and all the other things on the bug tracker, whether
they work or not.

To facilitate this copying or forking off, I would make the
copy of "master" be "gramps43" and not "gramps50" -- so that
the to-be-released gramps will be 4.3.0 and not 5.0.0. Just
to make it clear to all the users that it will not contain
what some of them have been dreaming it would contain,
whatever that might happen to be.

Similar to having the final decision as to what code will be
in the to-be-released gramps I will have the final decision
as to what bugs will be fixed before it's released -- ones
currently on the "5.0.0" and "5.0.0-alpha2" roadmaps that
is. The new 4.3.0 roadmap will start off empty, or with all
the already-fixed bugs, whatever makes sense to a bug
tracker administrator/wizard (which I am not).

If anybody feels a bug currently on the roadmap for 5.0.0 or
5.0.0-alpha2 should be moved to the new 4.3.0 roadmap, they
will have to convince me of that, which will probably
include promising to fix the bug itself -- in a reasonable
amount of time, say two or three weeks. If they don't,
it'll be moved back out of the 4.3.0 roadmap, the way we
used to do to bugs that were clearly not going to be fixed
before a release.

Another condition is that the same as I expect help from a
bug tracker administrator, to take care of the changes
there, I will likewise require a volunteer to be the one to
go through that wiki page on the things to do before a new
release, as Jerome has been doing for some years now and as
Steve Charette used to do before that. If Jerome wants to
volunteer to do that, that would be great, and then he will
be the one to generate the list of changes and fixed bugs,
and so forth, as well as the tar file which he'll upload.
If not, then somebody else will need to volunteer to do that
stage of the release, follow the wiki steps.

If people agree to this we can talk about timing. After a
new gramps43 maintenance branch is created, and purged of
the new-DB code and anything else which doesn't work yet, I
would propose that its condition be defined as "good enough
for wider release, to enable testing." Specifically I would
suggest that two "beta" releases be made, and that they be
made available on as many platforms as possible, so that as
many users as possible can test it.

If bugs are discovered we will see whether any developer is
willing to fix them. If so, great. If not, then I imagine
that feature/bug-fix/enhancement will be removed from the
gramps43 tree (while remaining in master), so as not to
delay the release of <the next gramps>.

Once bugs are fixed or in the process of being fixed, we'll
declare a "string freeze" for a week or two, to enable any
translator to do anything they want to do.

Thanks for reading this.

Any comments?

Paul Culley

2017-04-25 13:52:48 UTC

I am starting to free up some time again to work on Gramps, so please feel
free to point me to items that seem to be important for a new release.

That said, I wonder why we are so concerned about the new db code; it seems
to me that it works pretty well in what testing I have done. It can
definitely use more testing and the best way to do that is to turn it over
to users. Perhaps a warning that it may have some remaining issues, but
that it also should have some advantages; less likely to have fatal
corruption.
So I don't think the effort to remove or comment out the db code is worth
it.

As for the 'roadmap', I just looked over the GEPS list, and I cannot figure
out if all of these are officially 'on the roadmap' or not. Some of them
appear to be close to wishful thinking, others more practical but requiring
a lot of work, and some seem to me to be not really very important. Is it
possible that there is another 'roadmap' document I'm not aware of?

In my opinion, we would also need to fix up the wiki; copy 4.2.x
documentation to the new version and update for new functionality. I am
aware of several areas that need some attention there.

I also think we should make an effort to test and fix or classify ALL the
3rd party plugins for the new version, so that users will only see the ones
known to work.

I do agree that it is time for a new alpha or beta release of master code
(under whatever version number).

Just my thoughts...

Paul Culley

Unfortunately, I don't have the time to devote for a release.
We need someone to volunteer to be the 5.0 release manager. This person
will need to co-ordinate fixing the remaining issues on the roadmap,
testing and the release schedule. They will need to do extensive testing
themselves to ensure quality.
Any volunteers?
Nick.

As near as I can tell, Nick seems to be taking what I can
only describe as an overkill or extreme position, evidently
thinking that because he is the czar these days that
anything which goes out must be thoroughly tested, ideally
by him personally.
If this was happening in the past I was unaware of it. I
don't think we have the people to do that and I especially
don't think that the czar should do that. Anybody in that
position usually does far more than any normal developer's
share already.
I thought -- and still think -- that testing should be done
by everybody, in the normal course of things. Users too.
As I recall we used to (somehow) point power users at trunk
and ask them to put it through its paces. Besides all
developers using it of course.
The release of 5.0.0 is months behind any possible schedule.
After all, 4.2.0 was released (late) in August 2015, over a
year and a half ago. I proposed late last year that we
should release the then-current master as 4.3.0, after
purging all the new-DB code. But Nick didn't want that,
saying that he felt that 5.0.0 could be released by the end
of 2016.
Well, I don't know what he plans on doing to master, if
anything. He talks about "issues on the roadmap" but from
what I remember of past release cycles more than once we
simply decided certain "issues" wouldn't be fixed at all,
even if they happened to be on the roadmap.
I think we ought to declare the current "master" as "done"
or "good enough" or whatever, and branch off a maintenance
gramps from it. Maybe "ready for testing"?
He talked about a "release manager" but as far as I am
concerned that used to be -- and still is, assuming he is
willing -- Jerome. But I think a "release manager" is what
Steve Charette used to be, the person who takes the current
state of some repo tree and makes a tar file from it, then
uploads it.
In my mind a "release manager" has nothing to do with
personally checking every line of code in gramps, or
whatever Nick is thinking of.
We are woefully understaffed and we shouldn't think we can
continue as before. Our users will find any bugs. They
always have and they always will. Some of us will then try
to fix them.
Anything made by humans can never be perfect.
So since nobody has volunteered (publicly) in response to
Nick's query, here is what I explicitly propose.
I will personally take over the responsibility of seeing
that the <next gramps> is released.
But I will only do it if everybody agrees to my conditions,
or qualifications, or whatever you care to call them.
One is that I will have the final decision-making authority
as to what that <next gramps> will contain.
For instance I plan to entirely remove, or at least comment
out, all the new-DB code, wherever it is. And I do not mean
allowing it to "hide" behind a __debug_ flag as is presently
the case. This removal or elimination will happen in the
maintenance branch that "master" will become. The "master"
branch/repo will remain as it is now -- with all the new-DB
code and all the other things on the bug tracker, whether
they work or not.
To facilitate this copying or forking off, I would make the
copy of "master" be "gramps43" and not "gramps50" -- so that
the to-be-released gramps will be 4.3.0 and not 5.0.0. Just
to make it clear to all the users that it will not contain
what some of them have been dreaming it would contain,
whatever that might happen to be.
Similar to having the final decision as to what code will be
in the to-be-released gramps I will have the final decision
as to what bugs will be fixed before it's released -- ones
currently on the "5.0.0" and "5.0.0-alpha2" roadmaps that
is. The new 4.3.0 roadmap will start off empty, or with all
the already-fixed bugs, whatever makes sense to a bug
tracker administrator/wizard (which I am not).
If anybody feels a bug currently on the roadmap for 5.0.0 or
5.0.0-alpha2 should be moved to the new 4.3.0 roadmap, they
will have to convince me of that, which will probably
include promising to fix the bug itself -- in a reasonable
amount of time, say two or three weeks. If they don't,
it'll be moved back out of the 4.3.0 roadmap, the way we
used to do to bugs that were clearly not going to be fixed
before a release.
Another condition is that the same as I expect help from a
bug tracker administrator, to take care of the changes
there, I will likewise require a volunteer to be the one to
go through that wiki page on the things to do before a new
release, as Jerome has been doing for some years now and as
Steve Charette used to do before that. If Jerome wants to
volunteer to do that, that would be great, and then he will
be the one to generate the list of changes and fixed bugs,
and so forth, as well as the tar file which he'll upload.
If not, then somebody else will need to volunteer to do that
stage of the release, follow the wiki steps.
If people agree to this we can talk about timing. After a
new gramps43 maintenance branch is created, and purged of
the new-DB code and anything else which doesn't work yet, I
would propose that its condition be defined as "good enough
for wider release, to enable testing." Specifically I would
suggest that two "beta" releases be made, and that they be
made available on as many platforms as possible, so that as
many users as possible can test it.
If bugs are discovered we will see whether any developer is
willing to fix them. If so, great. If not, then I imagine
that feature/bug-fix/enhancement will be removed from the
gramps43 tree (while remaining in master), so as not to
delay the release of <the next gramps>.
Once bugs are fixed or in the process of being fixed, we'll
declare a "string freeze" for a week or two, to enable any
translator to do anything they want to do.
Thanks for reading this.
Any comments?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gramps-devel

Paul Franklin

2017-04-25 16:09:33 UTC

Post by Paul Culley
I am starting to free up some time again to work on Gramps, so please feel
free to point me to items that seem to be important for a new release.
That said, I wonder why we are so concerned about the new db code; it seems
to me that it works pretty well in what testing I have done. It can
definitely use more testing and the best way to do that is to turn it over
to users. Perhaps a warning that it may have some remaining issues, but
that it also should have some advantages; less likely to have fatal
corruption.
So I don't think the effort to remove or comment out the db code is worth
it.
As for the 'roadmap', I just looked over the GEPS list, and I cannot figure
out if all of these are officially 'on the roadmap' or not. Some of them
appear to be close to wishful thinking, others more practical but requiring
a lot of work, and some seem to me to be not really very important. Is it
possible that there is another 'roadmap' document I'm not aware of?
In my opinion, we would also need to fix up the wiki; copy 4.2.x
documentation to the new version and update for new functionality. I am
aware of several areas that need some attention there.
I also think we should make an effort to test and fix or classify ALL the
3rd party plugins for the new version, so that users will only see the ones
known to work.
I do agree that it is time for a new alpha or beta release of master code
(under whatever version number).
Just my thoughts...
Paul Culley

When I refer to "the roadmap" I am referring to this:

https://gramps-project.org/bugs/roadmap_page.php

That bug tracker roadmap page currently contains three
roadmaps, each of which can be accessed individually if
a person wants. I mean the 5.0.0 and 5.0.0-alpha2 ones,
not the 4.2.6 one.

I am not an expert in GEPS proposals but I believe the
way it works is that every such "gramps enhancement" is
just that, a major enhancement of gramps. I believe their
implementation -- if any -- and schedule -- if any -- is not
automatically connected with a new gramps release. But
other people may understand things better, or differently.
However, my understanding is that they are independent
of a "major" gramps release (one ending in zero, e.g.
5.0.0 or 4.3.0). although I would certainly guess that if a
GEPS is ever released that it would be done during such
a "major" release. Nothing else makes sense to me.

Yes, changing the wiki is also done for a new release.
I think NickW usually does the bulk-copy (say of gramps41
to gramps42), and then individual pages are tweaked if
necessary, say to add new report options.

I do not use third-party-addons myself but clearly they
must be in sync with whatever is released --as far as
version numbers are concerned. It seems to me that
in many cases such a bulk-upgrade is done without a
check being done to see that they actually work, but as
I said I don't really use them, so am really ignorant of the
process.

Perhaps those two things should be mentioned on:

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

which is the page I had in mind, about releases.

As to your comment about the new-DB code, your
opinion is certainly a perfectly valid one. It just happens
to be one I don't share.

If you feel strongly about it then I suggest you make an
explicit counter-proposal, as an alternative to mine. You
could state that you feel the new-DB code should be part
of the new gramps, and so on. You would of course then
also be volunteering to take responsibility for seeing that
the new gramps was created, with whatever you felt it
should have, deciding which bugs (on the two roadmaps
I mentioned for instance) would be fixed, and so on.

Paul Culley

2017-04-26 14:43:58 UTC

Please understand, I am volunteering to help, not to take over. I am of
the opinion that since I have not seen a new-DB related bug in quite a
while, despite using it quite a bit, that it may be ready for wider
review. And by avoiding the effort of removing the new-DB code, you free
up time for other things.

Going past that, I am willing to help deal with other bugs or tasks that
may be needed. Please let me know if there are particular items you think
I might handle. Otherwise I will continue to pick items from the bug
tracker roadmap page (silly me I searched for the roadmap on the wiki...).

For instance I note that the expanded tree view issue bug9880 has a PR 337
that is not complete and has been languishing. That one is a particular
annoyance of mine. I could try to finish it up. Or anything.

Paul Culley

Post by Paul Culley

Post by Paul Culley
I am starting to free up some time again to work on Gramps, so please

feel

Post by Paul Culley
free to point me to items that seem to be important for a new release.
That said, I wonder why we are so concerned about the new db code; it

seems

Post by Paul Culley
to me that it works pretty well in what testing I have done. It can
definitely use more testing and the best way to do that is to turn it

over

Post by Paul Culley
to users. Perhaps a warning that it may have some remaining issues, but
that it also should have some advantages; less likely to have fatal
corruption.
So I don't think the effort to remove or comment out the db code is worth
it.
As for the 'roadmap', I just looked over the GEPS list, and I cannot

figure

Post by Paul Culley
out if all of these are officially 'on the roadmap' or not. Some of them
appear to be close to wishful thinking, others more practical but

requiring

Post by Paul Culley
a lot of work, and some seem to me to be not really very important. Is

Post by Paul Culley
possible that there is another 'roadmap' document I'm not aware of?
In my opinion, we would also need to fix up the wiki; copy 4.2.x
documentation to the new version and update for new functionality. I am
aware of several areas that need some attention there.
I also think we should make an effort to test and fix or classify ALL the
3rd party plugins for the new version, so that users will only see the

ones

Post by Paul Culley
known to work.
I do agree that it is time for a new alpha or beta release of master code
(under whatever version number).
Just my thoughts...
Paul Culley

https://gramps-project.org/bugs/roadmap_page.php
That bug tracker roadmap page currently contains three
roadmaps, each of which can be accessed individually if
a person wants. I mean the 5.0.0 and 5.0.0-alpha2 ones,
not the 4.2.6 one.
I am not an expert in GEPS proposals but I believe the
way it works is that every such "gramps enhancement" is
just that, a major enhancement of gramps. I believe their
implementation -- if any -- and schedule -- if any -- is not
automatically connected with a new gramps release. But
other people may understand things better, or differently.
However, my understanding is that they are independent
of a "major" gramps release (one ending in zero, e.g.
5.0.0 or 4.3.0). although I would certainly guess that if a
GEPS is ever released that it would be done during such
a "major" release. Nothing else makes sense to me.
Yes, changing the wiki is also done for a new release.
I think NickW usually does the bulk-copy (say of gramps41
to gramps42), and then individual pages are tweaked if
necessary, say to add new report options.
I do not use third-party-addons myself but clearly they
must be in sync with whatever is released --as far as
version numbers are concerned. It seems to me that
in many cases such a bulk-upgrade is done without a
check being done to see that they actually work, but as
I said I don't really use them, so am really ignorant of the
process.
https://gramps-project.org/wiki/index.php?title=What_to_do_for_a_release
which is the page I had in mind, about releases.
As to your comment about the new-DB code, your
opinion is certainly a perfectly valid one. It just happens
to be one I don't share.
If you feel strongly about it then I suggest you make an
explicit counter-proposal, as an alternative to mine. You
could state that you feel the new-DB code should be part
of the new gramps, and so on. You would of course then
also be volunteering to take responsibility for seeing that
the new gramps was created, with whatever you felt it
should have, deciding which bugs (on the two roadmaps
I mentioned for instance) would be fixed, and so on.

Paul Franklin

2017-04-26 15:51:25 UTC

Post by Paul Culley
Please understand, I am volunteering to help, not to take over.

Yes, I can understand that you were trying to volunteer to
help. But you wanted to change what I proposed, also.

I explicitly said "But I will only do it if everybody agrees to
my conditions, or qualifications, or whatever you care to call
them."

You didn't agree, so that ended my offer to help, as far
as I am concerned. Which is why I suggested you could
make a counter-offer to take responsibility, which of course
I would then try to support as best I could.

If you don't want to do that, I can understand that too. I
hesitated quite a bit before making my offer. I am not eager
to do it, to take responsibility for getting a gramps released.
But I'm desperate for a new gramps. Somehow.

So perhaps you'll change your mind, and now want to take
responsibility, and then do things the way you feel they should
be done?

Or perhaps you'll change your mind a different way and agree
that I will have full control over what goes into the new gramps,
and what bugs people try to fix, and so on -- and explicitly say
so? Otherwise I guess we are back at the end of Nick's post,
where he was asking "Any volunteers?"

Post by Paul Culley
I am of
the opinion that since I have not seen a new-DB related bug in quite a
while, despite using it quite a bit, that it may be ready for wider
review. And by avoiding the effort of removing the new-DB code, you free
up time for other things.

Yes, you have made your point of view quite clear. But as I
said, I don't agree. I don't think a new database is critical
to the vast majority of gramps users. So either you should
volunteer to take over or else I'd appreciate it if you stopped
mentioning your point of view. I would rather not discuss it
every few days.

Post by Paul Culley
Going past that, I am willing to help deal with other bugs or tasks that
may be needed. Please let me know if there are particular items you think
I might handle. Otherwise I will continue to pick items from the bug
tracker roadmap page (silly me I searched for the roadmap on the wiki...).
For instance I note that the expanded tree view issue bug9880 has a PR 337
that is not complete and has been languishing. That one is a particular
annoyance of mine. I could try to finish it up. Or anything.

Anything that you want to do will be fine with me, assuming
you want me to continue trying to head this effort, and say so.

As long as the bug has nothing to do with DB-API code that is.
I think all of them should be ignored for now. Or perhaps the
word "ignored" is incorrect and it should really be "all pending
5.0.0-alpha2 bugs should be moved to 5.0.0" and all fixed bugs
from 5.0.0 and 5.0.0-alpha2 should be moved into a new 4.3.0,
once that is made (by some bug tracker administrator).

I suppose it seems to make more sense to me that any effort is
aimed at fixing problems in existing code. As opposed to a
new p.r. which adds some new feature. Starting a new p.r. now,
that is, doesn't make a lot of sense to me. Committing existing
ones seems like the right path towards a new gramps, if they
are either ready or can be made ready in a small number of days.

But I believe it is the case that there are some pull requests
which have been languishing for some time. I haven't been
following their status but if they could be finished soon and then
committed soon, that would seem to make sense to me. I
would rather see them committed and then see how many
people think they should be changed, if any, once we get into
the testing phase. As opposed to what seems to me to be
a semi-constant fine-tuning, which seems to be to be delaying
any release.

But talking about delaying, I'd really like to see more people
either reading this thread -- which I hope is already happening --
or else commenting on it. I specifically don't want to start a
lot of effort and then in a few weeks see people "coming out
of the woodwork" and saying this is all a bad idea and they are
against it. I know we don't have many active developers who
are coding things or fixing bugs, but surely expressing some
opinion isn't too much to ask.

If I'm going to take on this responsibility I'd like to see more
people saying it's all right with them.

Especially in areas where I have specifically asked for help.
Like making the bug tracker changes, and somebody saying
they will process that wiki page on releases -- including at least
two beta releases. And what about AIO and Mac packages,
for the beta releases I mean.

And if anybody disagrees with what I am proposing, I'd like
to see that too, so I can stop thinking about doing it and just
wait for somebody else to volunteer.

And so on.

Thanks.

Nick Hall

2017-04-26 18:32:23 UTC

Post by Paul Franklin
Or perhaps you'll change your mind a different way and agree
that I will have full control over what goes into the new gramps,
and what bugs people try to fix, and so on -- and explicitly say
so? Otherwise I guess we are back at the end of Nick's post,
where he was asking "Any volunteers?"

After consultation with the other developers, control over what goes
into Gramps resides with Brian, Benny and myself.

It looks like I may have to find time to do the job myself. Give me a
few days to examine the roadmap.

Nick.

Paul Franklin

2017-04-26 18:56:55 UTC

Post by Nick Hall
After consultation with the other developers, control over what goes
into Gramps resides with Brian, Benny and myself.

I am happy to be relieved of a responsibility I never really wanted.

Assuming of course that something really does happen this time.

Thank you.

Paul Franklin

2017-05-07 00:21:19 UTC

Post by Nick Hall
It looks like I may have to find time to do the job myself. Give me a
few days to examine the roadmap.

As it's been "a few days" I wonder if you can report any
progress (as I have not noticed any commits, reshuffled
roadmaps, etc.)?

Thanks.

Nick Hall

2017-05-07 17:35:52 UTC

Post by Nick Hall
It looks like I may have to find time to do the job myself. Give me a
few days to examine the roadmap.

As it's been "a few days" I wonder if you can report any
progress (as I have not noticed any commits, reshuffled
roadmaps, etc.)?

I previously got about 90% through the DBAPI tidy-up. Some of the
roadmap items can be removed, but I will post to the list before doing this.

Unfortunately, I have just found a problem with SQL transactions. Some
of the unit tests which use an in-memory sqlite database are failing on
my development machine.

Nick.

Paul Franklin

2017-05-07 19:53:48 UTC

Post by Nick Hall
It looks like I may have to find time to do the job myself. Give me a
few days to examine the roadmap.

As it's been "a few days" I wonder if you can report any
progress (as I have not noticed any commits, reshuffled
roadmaps, etc.)?

I previously got about 90% through the DBAPI tidy-up. Some of the
roadmap items can be removed, but I will post to the list before doing this.
Unfortunately, I have just found a problem with SQL transactions. Some
of the unit tests which use an in-memory sqlite database are failing on
my development machine.

Thank you for the status.

Paul Franklin

2017-05-21 17:15:42 UTC

Post by Nick Hall
Unfortunately, I have just found a problem with SQL transactions. Some
of the unit tests which use an in-memory sqlite database are failing on
my development machine.

Do you have any news?

Is 10038 the only problem [1]? Do you know what you will do?

Is that the only DB-API problem which needs fixing?

Are you going to fix it before you make the gramps50 branch?

Thanks.

[1] https://gramps-project.org/bugs/view.php?id=10038#c51773

Nick Hall

2017-05-22 18:33:32 UTC

Post by Nick Hall
Unfortunately, I have just found a problem with SQL transactions. Some
of the unit tests which use an in-memory sqlite database are failing on
my development machine.

Do you have any news?
Is 10038 the only problem [1]? Do you know what you will do?

I haven't had time to look at it further yet.

Post by Paul Franklin
Is that the only DB-API problem which needs fixing?

There may be more. I need to go through the roadmap.

Post by Paul Franklin
Are you going to fix it before you make the gramps50 branch?

Only if the fix is easy.

Post by Paul Franklin
Thanks.
[1]https://gramps-project.org/bugs/view.php?id=10038#c51773

Paul Franklin

2017-05-22 20:57:33 UTC

Post by Nick Hall
Unfortunately, I have just found a problem with SQL transactions. Some
of the unit tests which use an in-memory sqlite database are failing on
my development machine.

Do you have any news?
Is 10038 the only problem [1]? Do you know what you will do?

I haven't had time to look at it further yet.

Post by Paul Franklin
Is that the only DB-API problem which needs fixing?

There may be more. I need to go through the roadmap.

Post by Paul Franklin
Are you going to fix it before you make the gramps50 branch?

Only if the fix is easy.

Post by Paul Franklin
Thanks.
[1]https://gramps-project.org/bugs/view.php?id=10038#c51773

Thanks for the update.

I will remind you that a year ago, 16 Apr 2016, you said:

"A sensible alternative would be to release v4.3 in June, with BSDDB as
the default database."

If you don't have time now to investigate -- and fix -- all the
DB-API problems, I will again argue that releasing a 4.3.0
in a month or so, with the DB-API stuff deleted or whatever,
still makes sense to me. That's what I would have done.

That would get a new gramps out there, with all of the features
and new things which have been added, while removing any
pressure for you to come up with the time which you need to
fix the DB-API bugs and get a 5.0.0 release into shape.

I hope you will seriously consider that alternative.

I said back then that "I don't like the idea of doing major
development work so close to a release time" and I still feel
that way.

Thank you.

---------- Forwarded message ----------
From: Nick Hall <nick-***@gramps-project.org>
Date: Sat, 16 Apr 2016 15:25:25 +0100
Subject: Re: [Gramps-devel] Preparation for Gramps 5.0
To: gramps-***@lists.sourceforge.net

Paul,

A sensible alternative would be to release v4.3 in June, with BSDDB as
the default database.

The Select API / QuerySet interface should also be removed. As I have
already mentioned, agreement was never reached on this.

Efficient select functionality could then be fully integrated into the
filters for a release of v5.0 in June 2017.

Nick.

Post by Nick Hall
I am totally against making such a major change so late in the
cycle for 5.0.
If you wanted to propose making DB-API the default, instead
of BSDDB, you should have proposed doing that last July, and
if it was then agreed upon -- last July -- there would have been
almost a year of testing, for instance on Windows.
Unless I'm wrong this will be the first gramps release where it
is even >possible< to have a choice of second type of database.
I don't think making it the default is the right thing to do, right now.
Why not have a discussion -- right now -- as to whether it should
become the default when 5.1 is released (in July 2017?)? If that
is decided upon, we can announce when we release 5.0 that it
is now possible and that we encourage all (brave? power user?)
users who want to try it, to try it -- and perhaps suggest making
frequent (daily?) gramps XML backups as they go along.
I don't like the idea of doing major development work so close
to a release time.
We should be thinking about our users, not our coding.

Tim Lyons

2017-05-03 22:12:44 UTC