Quantcast

gramps50 and 5.0.0

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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