gramps50 and 5.0.0

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

gramps50 and 5.0.0

Paul Franklin-5
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?

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

Re: gramps50 and 5.0.0

Nick Hall
On 13/04/17 08:42, Paul Franklin wrote:
> 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.



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

Re: gramps50 and 5.0.0

Paul Franklin-5
On 4/17/17, Nick Hall <[hidden email]> wrote:

> On 13/04/17 08:42, Paul Franklin wrote:
>> 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.



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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: gramps50 and 5.0.0

prculley
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

On Mon, Apr 24, 2017 at 8:27 PM, Paul Franklin <[hidden email]> wrote:
On 4/17/17, Nick Hall <[hidden email]> wrote:
> On 13/04/17 08:42, Paul Franklin wrote:
>> 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.



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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


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

Re: gramps50 and 5.0.0

Paul Franklin-5
On 4/25/17, Paul Culley <[hidden email]> wrote:

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

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

Re: gramps50 and 5.0.0

prculley
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

On Tue, Apr 25, 2017 at 11:09 AM, Paul Franklin <[hidden email]> wrote:
On 4/25/17, Paul Culley <[hidden email]> wrote:
> 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.


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

Re: gramps50 and 5.0.0

Paul Franklin-5
On 4/26/17, Paul Culley <[hidden email]> wrote:
> 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?"

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

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

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

Re: gramps50 and 5.0.0

Nick Hall
On 26/04/17 16:51, Paul Franklin wrote:
> 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.



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

Re: gramps50 and 5.0.0

Paul Franklin-5
On 4/26/17, Nick Hall <[hidden email]> wrote:
> 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.

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

Re: gramps50 and 5.0.0

Tim Lyons
Administrator
In reply to this post by prculley
prculley wrote
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.
The history of the concern over the database code.

We have had a _lot_ of problems reported, both in the bug reports and in the mailing lists, about [BSDDB] database corruption. The problem is that we have seldom been able to reproduce the problems and hence been unable to fix them. So testing has been unable to even create the problems, let alone identify what the cause(s) might be.

In fact, if problems are related to program crashes or system crashes at inopportune moments it is probably impossible to reproduce these situations without specially constructed/modified database software. (The documentation of one of the database engines - I don't remember whether I read it under BSDDB or sqlite - does refer to specially modified code to do such tests).

In respect of sqlite, quite a number of problems have been identified by reading the code - I don't know that many have been found by testing! (No doubt with more use, more errors will be observed during use, but whether they will be able to be reproduced and hence fixed is a bit unknown).

I think that one of the problems with BSDDB might be that there are many options, while the sqlite code may be simpler because there are fewer options, but has had less exposure to use.

I think all of this accounts for what may or may not be an excess of caution.

The above discussion should not be taken as providing any opinion as to whether the db code should be removed or not - that's an entirely different question, which I don't want to address in this message.

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

Re: gramps50 and 5.0.0

Paul Franklin-5
In reply to this post by Nick Hall
On 4/26/17, Nick Hall <[hidden email]> wrote:
> 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.

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

Re: gramps50 and 5.0.0

Nick Hall
On 07/05/17 01:21, Paul Franklin wrote:
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.



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

Re: gramps50 and 5.0.0

Paul Franklin-5
On 5/7/17, Nick Hall <[hidden email]> wrote:

> On 07/05/17 01:21, Paul Franklin wrote:
>>> 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.

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

Re: gramps50 and 5.0.0

Paul Franklin-5
In reply to this post by Nick Hall
On 5/7/17, Nick Hall <[hidden email]> wrote:
> 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

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

Re: gramps50 and 5.0.0

Nick Hall
On 21/05/17 18:15, Paul Franklin wrote:
On 5/7/17, Nick Hall [hidden email] wrote:
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.


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

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


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

Only if the fix is easy.



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

Re: gramps50 and 5.0.0

Paul Franklin-5
On 5/22/17, Nick Hall <[hidden email]> wrote:

> On 21/05/17 18:15, Paul Franklin wrote:
>> On 5/7/17, Nick Hall<[hidden email]>  wrote:
>>> 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.
>
>>
>> Is that the only DB-API problem which needs fixing?
>
> There may be more.  I need to go through the roadmap.
>
>>
>> Are you going to fix it before you make the gramps50 branch?
>
> Only if the fix is easy.
>
>>
>> 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 <[hidden email]>
Date: Sat, 16 Apr 2016 15:25:25 +0100
Subject: Re: [Gramps-devel] Preparation for Gramps 5.0
To: [hidden email]

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.


On 13/04/16 05:52, Paul Franklin wrote:

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

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