Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-10 Thread John Ralls



> On 10. Jun 2018, at 13:41, Christian Stimming  wrote:
> 
> Am Samstag, 2. Juni 2018, 17:28:27 schrieb John Ralls:
>>> there is already a private fork, just as everyone else
>>> around here is free to privately fork anything that he/she wants.
>>> https://github.com/cstim/gnucash/tree/branch-2.6
>> 
>> BTW, there's already a 2.6.21 because the MySQL backend was broken on
>> 2.6.20. It was released April 10.
> 
> Dear John,
> 
> yes I confused the numbers here. There was a 2.6.21 in April. I would happily 
> switch to the 3.0 branch (git-maint) on my system, as soon as I see for 
> myself 
> that it is up and running on my (still old) ubuntu 14.04 system.
> 
> However, after I eventually was able to build and run the newer branch [1], 
> it 
> turns out to crash in the register on every normal usage. Of course I've 
> filed 
> a bug on that one [2] (with gtk-3.10.8 that is), and I will continue looking 
> into resolving this problem myself, too. However, until we are able to 
> resolve 
> this problem, my guess is that on ubuntu 14.04, there is no 3.0.x version 
> that 
> is usable. Can someone report otherwise? If yes, I would happily discuss in 
> detail the steps that I'm missing.
> 
> Until then, I would again propose to keep a 2.6 branch alive for a few more 
> months, so that a potential 2.6.22 release with minor bugfixes might be 
> released as well for systems on the age of ubuntu 14.04.
> 
> Best Regards,
> 
> Christian
> 
> [1] For several days, I was stuck at the error at start-up "Undefined 
> variable: gnc-build-userdata-path" that got reported also by e.g. Herbert 
> Thoma here. For future reference: The solution was to remove any instance of 
> an old (2.6) gnucash from the library path both at build time and at run time.
> 
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=796556
> 

Christian,

Your crash appears to be a dupe of a Gtk bug, details and a possible 
work-around on your bug report.

You seem to have missed out that we've changed the version system, there's no 
3.0.x at all. There was 3.0, the current release is 3.1, and the next one will 
be 3.2.

I'm not interested in continually re-arguing further 2.6.x releases.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-10 Thread Christian Stimming
Am Samstag, 2. Juni 2018, 17:28:27 schrieb John Ralls:
> > there is already a private fork, just as everyone else
> > around here is free to privately fork anything that he/she wants.
> > https://github.com/cstim/gnucash/tree/branch-2.6
> 
> BTW, there's already a 2.6.21 because the MySQL backend was broken on
> 2.6.20. It was released April 10.

Dear John,

yes I confused the numbers here. There was a 2.6.21 in April. I would happily 
switch to the 3.0 branch (git-maint) on my system, as soon as I see for myself 
that it is up and running on my (still old) ubuntu 14.04 system.

However, after I eventually was able to build and run the newer branch [1], it 
turns out to crash in the register on every normal usage. Of course I've filed 
a bug on that one [2] (with gtk-3.10.8 that is), and I will continue looking 
into resolving this problem myself, too. However, until we are able to resolve 
this problem, my guess is that on ubuntu 14.04, there is no 3.0.x version that 
is usable. Can someone report otherwise? If yes, I would happily discuss in 
detail the steps that I'm missing.

Until then, I would again propose to keep a 2.6 branch alive for a few more 
months, so that a potential 2.6.22 release with minor bugfixes might be 
released as well for systems on the age of ubuntu 14.04.

Best Regards,

Christian

[1] For several days, I was stuck at the error at start-up "Undefined 
variable: gnc-build-userdata-path" that got reported also by e.g. Herbert 
Thoma here. For future reference: The solution was to remove any instance of 
an old (2.6) gnucash from the library path both at build time and at run time.

[2] https://bugzilla.gnome.org/show_bug.cgi?id=796556

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-03 Thread David T. via gnucash-devel
+1 on all fronts. Thank you Adrien.

> On Jun 3, 2018, at 10:02 AM, Adrien Monteleone 
>  wrote:
> 
> Folks,
> 
> Perhaps my comments are not wanted, or out of place, but as an active user, 
> someone who contributes a bit of assistance on the mailing list, and just 
> someone who in general helps people less knowledgable with software 
> selections and support, I have to ask, “Christian, did you consider the 
> impact on complete newbies who might stumble upon and install, for whatever 
> reason, the 2.6.x branch?” Or even someone who is still running it and 
> contemplating an upgrade? As someone who helps out mom and pop businesses 
> adopt GnuCash, the prospect of installing a full major version behind, bugs 
> and all, less functionality, et cetera, and WASTING their time would leave me 
> and them, nothing short of extremely perturbed when we eventually find out 
> there is a more recent version. (*I* know now, but *they* won’t and they 
> might not find me until afterwards, and what of others like me just entering 
> this journey?) Sure, *I* can see where it would be ’nice’ to maintain an 
> older version for certain ‘cut-off’ compatibility reasons, but those *are* 
> the reason for a fork. (really, though, your initial stated reason was a 
> compiling problem, which I though John answered adequately) I sure don’t want 
> to have to repeatedly explain to people that 2.6.x is not supported if there 
> is an ‘official’ branch in the Git repo available. (not that newbies would be 
> looking there mind you, but one thing I’ve learned with this project is you 
> can’t count on what you expect from how people ‘find’ you or install the 
> software.)
> 
> I’m not a dev so I have a less than important perspective, but perhaps you 
> should be aware, that there are some out here who aren’t devs who would not 
> be appreciative of more than one official version that wasn’t actually an 
> actively and officially supported version. I don’t know of any software 
> project where that is acceptable. (If it isn’t supported, it isn’t 
> ‘official’) It isn’t a matter of what is possible that can function or not, 
> it’s a matter of expectation of what is supported and what isn’t. If the main 
> devs don’t want to, or don’t have the resources to, support more than one 
> version, then the answer is a fork. Please consider you might be making life 
> unpleasant for more than just whatever you are willing to take one. You are 
> obligating many others and you are creating an expectation you can’t even 
> fully scope, much less fulfill. (or even at least initially be called to 
> fulfill) Others are going have to have to deal with this ‘old version’ for as 
> long as it exists, not just you.
> 
> Regards,
> Adrien
> 
> 
> 
>> On Jun 2, 2018, at 7:28 PM, John Ralls  wrote:
>> 
>> 
>> 
>>> On Jun 2, 2018, at 2:05 PM, Christian Stimming  
>>> wrote:
>>> 
>>> Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
>> But why do we keep a "gnucash" repo at all and not only everyone's
>> personal
>> repository? Of course there is some sort of project belonging. My
>> proposal
>> is to still keep the 2.6 branch a little bit more alive, and one or two
>> maintenance releases might be spun off from there. I'd be the one who
>> does
>> the housekeeping there, as discussed already.
> 
> Considering you do offer to take care of that 2.6 branch I can live with
> having one. If John disagrees you may need to make it a core policy
> decision request and check for a broader opinion there.
 
 I disagree for the user and contributor confusion reasons already stated,
 because I think that the old Windows build system should be retired, and
 because I think Christian has forgotten how much work goes into support and
 won’t have time to devote to it.
 
 If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
 but it should be clear to all that it’s Christian’s fork and not “Official"
 GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
 public repository with its own bug tracker and its own support mailing
 list. It’s 10 minutes work to set all of that up on Github, so what’s the
 point of keeping it in the Github repository?
>>> 
>>> *sigh* Of course there is already a private fork, just as everyone else 
>>> around 
>>> here is free to privately fork anything that he/she wants. 
>>> https://github.com/cstim/gnucash/tree/branch-2.6
>>> However, that's not the point of our common project gnucash. "Official", as 
>>> you call it.
>>> 
>>> Talking of core policy decision: Ultimately the decision is about whether 
>>> there might be another 2.6.x release after the 2.6.20 in April, which in 
>>> turn 
>>> is the reason for the existence of any 2.6 branch. John, it seems you 
>>> decided 
>>> that there should not be any such release anymore under any circumstances. 
>>> Had 
>>> this been a decision following 

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-02 Thread Adrien Monteleone
Folks,

Perhaps my comments are not wanted, or out of place, but as an active user, 
someone who contributes a bit of assistance on the mailing list, and just 
someone who in general helps people less knowledgable with software selections 
and support, I have to ask, “Christian, did you consider the impact on complete 
newbies who might stumble upon and install, for whatever reason, the 2.6.x 
branch?” Or even someone who is still running it and contemplating an upgrade? 
As someone who helps out mom and pop businesses adopt GnuCash, the prospect of 
installing a full major version behind, bugs and all, less functionality, et 
cetera, and WASTING their time would leave me and them, nothing short of 
extremely perturbed when we eventually find out there is a more recent version. 
(*I* know now, but *they* won’t and they might not find me until afterwards, 
and what of others like me just entering this journey?) Sure, *I* can see where 
it would be ’nice’ to maintain an older version for certain ‘cut-off’ 
compatibility reasons, but those *are* the reason for a fork. (really, though, 
your initial stated reason was a compiling problem, which I though John 
answered adequately) I sure don’t want to have to repeatedly explain to people 
that 2.6.x is not supported if there is an ‘official’ branch in the Git repo 
available. (not that newbies would be looking there mind you, but one thing 
I’ve learned with this project is you can’t count on what you expect from how 
people ‘find’ you or install the software.)

I’m not a dev so I have a less than important perspective, but perhaps you 
should be aware, that there are some out here who aren’t devs who would not be 
appreciative of more than one official version that wasn’t actually an actively 
and officially supported version. I don’t know of any software project where 
that is acceptable. (If it isn’t supported, it isn’t ‘official’) It isn’t a 
matter of what is possible that can function or not, it’s a matter of 
expectation of what is supported and what isn’t. If the main devs don’t want 
to, or don’t have the resources to, support more than one version, then the 
answer is a fork. Please consider you might be making life unpleasant for more 
than just whatever you are willing to take one. You are obligating many others 
and you are creating an expectation you can’t even fully scope, much less 
fulfill. (or even at least initially be called to fulfill) Others are going 
have to have to deal with this ‘old version’ for as long as it exists, not just 
you.

Regards,
Adrien

 

> On Jun 2, 2018, at 7:28 PM, John Ralls  wrote:
> 
> 
> 
>> On Jun 2, 2018, at 2:05 PM, Christian Stimming  
>> wrote:
>> 
>> Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
> But why do we keep a "gnucash" repo at all and not only everyone's
> personal
> repository? Of course there is some sort of project belonging. My
> proposal
> is to still keep the 2.6 branch a little bit more alive, and one or two
> maintenance releases might be spun off from there. I'd be the one who
> does
> the housekeeping there, as discussed already.
 
 Considering you do offer to take care of that 2.6 branch I can live with
 having one. If John disagrees you may need to make it a core policy
 decision request and check for a broader opinion there.
>>> 
>>> I disagree for the user and contributor confusion reasons already stated,
>>> because I think that the old Windows build system should be retired, and
>>> because I think Christian has forgotten how much work goes into support and
>>> won’t have time to devote to it.
>>> 
>>> If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
>>> but it should be clear to all that it’s Christian’s fork and not “Official"
>>> GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
>>> public repository with its own bug tracker and its own support mailing
>>> list. It’s 10 minutes work to set all of that up on Github, so what’s the
>>> point of keeping it in the Github repository?
>> 
>> *sigh* Of course there is already a private fork, just as everyone else 
>> around 
>> here is free to privately fork anything that he/she wants. 
>> https://github.com/cstim/gnucash/tree/branch-2.6
>> However, that's not the point of our common project gnucash. "Official", as 
>> you call it.
>> 
>> Talking of core policy decision: Ultimately the decision is about whether 
>> there might be another 2.6.x release after the 2.6.20 in April, which in 
>> turn 
>> is the reason for the existence of any 2.6 branch. John, it seems you 
>> decided 
>> that there should not be any such release anymore under any circumstances. 
>> Had 
>> this been a decision following our decision process,
>> https://wiki.gnucash.org/wiki/Decision_process
>> , I would have been the voice that raises a objection to that decision.
>> 
>> From my point of view, April isn't too far away and there might indeed be a 
>> 

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-02 Thread John Ralls


> On Jun 2, 2018, at 2:05 PM, Christian Stimming  wrote:
> 
> Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
 But why do we keep a "gnucash" repo at all and not only everyone's
 personal
 repository? Of course there is some sort of project belonging. My
 proposal
 is to still keep the 2.6 branch a little bit more alive, and one or two
 maintenance releases might be spun off from there. I'd be the one who
 does
 the housekeeping there, as discussed already.
>>> 
>>> Considering you do offer to take care of that 2.6 branch I can live with
>>> having one. If John disagrees you may need to make it a core policy
>>> decision request and check for a broader opinion there.
>> 
>> I disagree for the user and contributor confusion reasons already stated,
>> because I think that the old Windows build system should be retired, and
>> because I think Christian has forgotten how much work goes into support and
>> won’t have time to devote to it.
>> 
>> If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
>> but it should be clear to all that it’s Christian’s fork and not “Official"
>> GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
>> public repository with its own bug tracker and its own support mailing
>> list. It’s 10 minutes work to set all of that up on Github, so what’s the
>> point of keeping it in the Github repository?
> 
> *sigh* Of course there is already a private fork, just as everyone else 
> around 
> here is free to privately fork anything that he/she wants. 
> https://github.com/cstim/gnucash/tree/branch-2.6
> However, that's not the point of our common project gnucash. "Official", as 
> you call it.
> 
> Talking of core policy decision: Ultimately the decision is about whether 
> there might be another 2.6.x release after the 2.6.20 in April, which in turn 
> is the reason for the existence of any 2.6 branch. John, it seems you decided 
> that there should not be any such release anymore under any circumstances. 
> Had 
> this been a decision following our decision process,
> https://wiki.gnucash.org/wiki/Decision_process
> , I would have been the voice that raises a objection to that decision.
> 
> From my point of view, April isn't too far away and there might indeed be a 
> 2.6.21 with some bugfixes. This is not a long-term commitment, just for maybe 
> another few months after the 2.6.20 release. How big is the risk in accepting 
> this objection and allow a potential 2.6.21 release to show up in the near 
> future? I'm surprised to see that prohibited from your side to begin with.

Christian,

Sigh yourself.

As I pointed out before, there is no new policy. As far as I can tell from the 
repo's history GnuCash has *never* maintained two stable branches. Ever. We're 
following that practice by end-of-lifing 2.6 with the release of 3.0. If there 
needs to be a core decision it's to change that policy, not to continue it.

BTW, there's already a 2.6.21 because the MySQL backend was broken on 2.6.20. 
It was released April 10. 

How is it not a long-term commitment? There's no end to "just one more".

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-02 Thread Christian Stimming
Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
> >> But why do we keep a "gnucash" repo at all and not only everyone's
> >> personal
> >> repository? Of course there is some sort of project belonging. My
> >> proposal
> >> is to still keep the 2.6 branch a little bit more alive, and one or two
> >> maintenance releases might be spun off from there. I'd be the one who
> >> does
> >> the housekeeping there, as discussed already.
> > 
> > Considering you do offer to take care of that 2.6 branch I can live with
> > having one. If John disagrees you may need to make it a core policy
> > decision request and check for a broader opinion there.
> 
> I disagree for the user and contributor confusion reasons already stated,
> because I think that the old Windows build system should be retired, and
> because I think Christian has forgotten how much work goes into support and
> won’t have time to devote to it.
> 
> If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
> but it should be clear to all that it’s Christian’s fork and not “Official"
> GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
> public repository with its own bug tracker and its own support mailing
> list. It’s 10 minutes work to set all of that up on Github, so what’s the
> point of keeping it in the Github repository?

*sigh* Of course there is already a private fork, just as everyone else around 
here is free to privately fork anything that he/she wants. 
https://github.com/cstim/gnucash/tree/branch-2.6
However, that's not the point of our common project gnucash. "Official", as 
you call it.

Talking of core policy decision: Ultimately the decision is about whether 
there might be another 2.6.x release after the 2.6.20 in April, which in turn 
is the reason for the existence of any 2.6 branch. John, it seems you decided 
that there should not be any such release anymore under any circumstances. Had 
this been a decision following our decision process,
https://wiki.gnucash.org/wiki/Decision_process
, I would have been the voice that raises a objection to that decision.

From my point of view, April isn't too far away and there might indeed be a 
2.6.21 with some bugfixes. This is not a long-term commitment, just for maybe 
another few months after the 2.6.20 release. How big is the risk in accepting 
this objection and allow a potential 2.6.21 release to show up in the near 
future? I'm surprised to see that prohibited from your side to begin with.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-02 Thread John Ralls


> On Jun 2, 2018, at 1:10 AM, Geert Janssens  wrote:
> 
> Op woensdag 30 mei 2018 22:31:03 CEST schreef Christian Stimming:
>> Am Dienstag, 29. Mai 2018, 06:56:44 schrieb John Ralls:
 On May 29, 2018, at 5:04 AM, Geert Janssens 
 wrote:
 
 or at best on a branch that clearly shows it's not maintained by the
 currently active gnucash community (like a cstim-2.6 branch or something
 similar).
>>> 
>>> Git != SVN. There is *no reason* for personal branches in a git
>>> repository.
>>> Everyone has their own repository and can easily publish it on Github or
>>> similar services. That’s where personal branches belong.
>> 
>> But why do we keep a "gnucash" repo at all and not only everyone's personal
>> repository? Of course there is some sort of project belonging. My proposal
>> is to still keep the 2.6 branch a little bit more alive, and one or two
>> maintenance releases might be spun off from there. I'd be the one who does
>> the housekeeping there, as discussed already.
>> 
>> Nevertheless thanks for the pointers about building on Ubuntu 14.04, I'll
>> look into this for the time being. I'd still like to have the 2.6 branch
>> slightly longer alive, though.
> 
> Considering you do offer to take care of that 2.6 branch I can live with 
> having one. If John disagrees you may need to make it a core policy decision 
> request and check for a broader opinion there.

I disagree for the user and contributor confusion reasons already stated, 
because I think that the old Windows build system should be retired, and 
because I think Christian has forgotten how much work goes into support and 
won’t have time to devote to it.

If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so, but 
it should be clear to all that it’s Christian’s fork and not “Official" 
GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own 
public repository with its own bug tracker and its own support mailing list. 
It’s 10 minutes work to set all of that up on Github, so what’s the point of 
keeping it in the Github repository?

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-06-02 Thread Geert Janssens
Op woensdag 30 mei 2018 22:31:03 CEST schreef Christian Stimming:
> Am Dienstag, 29. Mai 2018, 06:56:44 schrieb John Ralls:
> > > On May 29, 2018, at 5:04 AM, Geert Janssens 
> > > wrote:
> > > 
> > > or at best on a branch that clearly shows it's not maintained by the
> > > currently active gnucash community (like a cstim-2.6 branch or something
> > > similar).
> > 
> > Git != SVN. There is *no reason* for personal branches in a git
> > repository.
> > Everyone has their own repository and can easily publish it on Github or
> > similar services. That’s where personal branches belong.
> 
> But why do we keep a "gnucash" repo at all and not only everyone's personal
> repository? Of course there is some sort of project belonging. My proposal
> is to still keep the 2.6 branch a little bit more alive, and one or two
> maintenance releases might be spun off from there. I'd be the one who does
> the housekeeping there, as discussed already.
> 
> Nevertheless thanks for the pointers about building on Ubuntu 14.04, I'll
> look into this for the time being. I'd still like to have the 2.6 branch
> slightly longer alive, though.

Considering you do offer to take care of that 2.6 branch I can live with 
having one. If John disagrees you may need to make it a core policy decision 
request and check for a broader opinion there.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-05-30 Thread Christian Stimming
Am Dienstag, 29. Mai 2018, 06:56:44 schrieb John Ralls:
> > On May 29, 2018, at 5:04 AM, Geert Janssens 
> > wrote:
> > 
> > or at best on a branch that clearly shows it's not maintained by the
> > currently active gnucash community (like a cstim-2.6 branch or something
> > similar).
>
> Git != SVN. There is *no reason* for personal branches in a git repository.
> Everyone has their own repository and can easily publish it on Github or
> similar services. That’s where personal branches belong.

But why do we keep a "gnucash" repo at all and not only everyone's personal 
repository? Of course there is some sort of project belonging. My proposal is 
to still keep the 2.6 branch a little bit more alive, and one or two 
maintenance releases might be spun off from there. I'd be the one who does the 
housekeeping there, as discussed already.

Nevertheless thanks for the pointers about building on Ubuntu 14.04, I'll look 
into this for the time being. I'd still like to have the 2.6 branch slightly 
longer alive, though.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-05-29 Thread John Ralls


> On May 29, 2018, at 5:04 AM, Geert Janssens  
> wrote:
> 
> or at best on a branch that clearly shows it's not maintained by the 
> currently 
> active gnucash community (like a cstim-2.6 branch or something similar).
> 

Git != SVN. There is *no reason* for personal branches in a git repository. 
Everyone has their own repository and can easily publish it on Github or 
similar services. That’s where personal branches belong.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-05-29 Thread Geert Janssens
Hi Christian,

John makes some valid points especially about the maintenance burden.

However on the other hand I have been musing supporting multiple stable 
versions side by side. So in a way I do appreciate your proposal to maintain a 
2.6 version.

Given the limited available time of the currently active developers I think 
this can only happen if you indeed want to take responsibility of such a 2.6 
branch (let's call it "extended support"). In that case I would be fine with 
that even in the official gnucash repository.

Full responsibility for me means that you or other volunteers you find ensure 
it doesn't increase our current workload. Which means I would expect you (or 
other volunteers) to handle 2.6 related PR's, do the 2.6 releases when you 
deem appropriate and be first level support for questions on 2.6.21+ releases. 
If the issues are not specific to 2.6.21+, of course the questions can be 
delegated back to gnucash support channels in general.

This will ask more commitment than just pushing a few commits useful to your 
private projects on a branch in our repository. If that is more than you (or 
someone else) can commit to (which could be perfectly reasonable) I do agree 
with John the primary gnucash git repository is not the place to manage this - 
or at best on a branch that clearly shows it's not maintained by the currently 
active gnucash community (like a cstim-2.6 branch or something similar).

That's my 2c.

Best regards,

Geert

Op maandag 28 mei 2018 01:48:01 CEST schreef John Ralls:
> > On May 27, 2018, at 12:50 PM, Christian Stimming 
> > wrote:
> > 
> > Dear John,
> > 
> > I did notice that the 2.6 branch was deleted (meaning: "maint" is now the
> > 3.x branch), but I didn't understand the reasons and didn't see any
> > discussion of this decision. I have some requirements which I can meet
> > most easily by just continuing the 2.6 version of gnucash, but this in
> > turn needed some occasional commits there. For example, I'm still running
> > Ubuntu 14.04 for reasons beyond the scope of gnucash, and I haven't been
> > able to build the 3.x branch on that machine because of missing packages.
> > At the same time the 2.6 branch met all that I needed for everyday work,
> > so I just stick to this.
> > 
> > Hence, I don't quite understand why there is such a strong requirement to
> > prohibit specifically any further existence of a 2.6 branch, and why you
> > use strong language to underline your point of view here. Also, it's a
> > bit puzzeling to me why you suggest me of all people to "change the name
> > and artwork" in case of a 2.6 branch - what have I missed here?? Where
> > was the discussion that led to this decision? Where was the decision
> > process, if this were the project's decision? Maybe some more liberality
> > for other people and their different requirements might be more suitable
> > on your side, before calling other people's requirements a "fantasy".
> > 
> > This particular pull request for the 2.6 branch showed up only one week
> > after I created that branch. To me, this looks like there are still more
> > people interested in such a branch. Of course, nothing new will happen
> > there, but the interest still exists.
> > 
> > For this reason I propose to keep some old 2.6 branch still up and running
> > in the gnucash repository. I would volunteer to act as an owner of that
> > branch, in case this is needed, but on the other hand we didn't need any
> > such designated branch maintainers for the most part. Further voices?
> > objections? ideas? Thanks.
> 
> Christian,
> 
> Sorry that I wasn't clear.
> 
> Geert and I decided after an IRC discussion that the simplest way to switch
> unstable to maint was to simply merge unstable onto maint and to remove the
> unstable branch, which is what we did. The 2.6.x releases are all tagged.
> Git isn't SVN, there's no need for a 2.6  branch to record what was in each
> release. The only reason for a separate branch is to develop a fork.
> 
> As you should be aware, we're very short of developer resources. We very
> simply cannot maintain two stable branches and still have time to also
> develop for the next major release. That's even more true now than it was 4
> years ago after we stopped development on 2.4 because you and Phil
> Longstaff were regularly working on GnuCash then; both of you have left and
> no one has come forward at the same level of effort.
> 
> As far as I can tell there have never been two stable branches maintained in
> parallel, so the question about a policy decision falls on you, not me.
> Where was the discussion to revive and maintain the 2.6.x branch after the
> release of 3.0? I know the answer: There wasn't one. You *unilaterally*
> decided to impose your personal requirements on the rest of the team by
> creating a branch and implying on a bug report [1] that it was possible
> that we'd have future releases. Sorry, that's a fantasy. We don't have the
> resources. Your branch 

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-05-27 Thread John Ralls

> On May 27, 2018, at 12:50 PM, Christian Stimming  
> wrote:
> 
> Dear John,
> 
> I did notice that the 2.6 branch was deleted (meaning: "maint" is now the 3.x 
> branch), but I didn't understand the reasons and didn't see any discussion of 
> this decision. I have some requirements which I can meet most easily by just 
> continuing the 2.6 version of gnucash, but this in turn needed some 
> occasional 
> commits there. For example, I'm still running Ubuntu 14.04 for reasons beyond 
> the scope of gnucash, and I haven't been able to build the 3.x branch on that 
> machine because of missing packages. At the same time the 2.6 branch met all 
> that I needed for everyday work, so I just stick to this.
> 
> Hence, I don't quite understand why there is such a strong requirement to 
> prohibit specifically any further existence of a 2.6 branch, and why you use 
> strong language to underline your point of view here. Also, it's a bit 
> puzzeling to me why you suggest me of all people to "change the name and 
> artwork" in case of a 2.6 branch - what have I missed here?? Where was the 
> discussion that led to this decision? Where was the decision process, if this 
> were the project's decision? Maybe some more liberality for other people and 
> their different requirements might be more suitable on your side, before 
> calling other people's requirements a "fantasy".
> 
> This particular pull request for the 2.6 branch showed up only one week after 
> I created that branch. To me, this looks like there are still more people 
> interested in such a branch. Of course, nothing new will happen there, but 
> the 
> interest still exists.
> 
> For this reason I propose to keep some old 2.6 branch still up and running in 
> the gnucash repository. I would volunteer to act as an owner of that branch, 
> in case this is needed, but on the other hand we didn't need any such 
> designated branch maintainers for the most part. Further voices? objections? 
> ideas? Thanks.
> 

Christian,

Sorry that I wasn't clear.

Geert and I decided after an IRC discussion that the simplest way to switch 
unstable to maint was to simply merge unstable onto maint and to remove the 
unstable branch, which is what we did. The 2.6.x releases are all tagged. Git 
isn't SVN, there's no need for a 2.6  branch to record what was in each 
release. The only reason for a separate branch is to develop a fork.

As you should be aware, we're very short of developer resources. We very simply 
cannot maintain two stable branches and still have time to also develop for the 
next major release. That's even more true now than it was 4 years ago after we 
stopped development on 2.4 because you and Phil Longstaff were regularly 
working on GnuCash then; both of you have left and no one has come forward at 
the same level of effort. 

As far as I can tell there have never been two stable branches maintained in 
parallel, so the question about a policy decision falls on you, not me. Where 
was the discussion to revive and maintain the 2.6.x branch after the release of 
3.0? I know the answer: There wasn't one. You *unilaterally* decided to impose 
your personal requirements on the rest of the team by creating a branch and 
implying on a bug report [1] that it was possible that we'd have future 
releases. Sorry, that's a fantasy. We don't have the resources. Your branch 
already caused someone to waste their time making a PR [2] in the mistaken 
belief that they were contributing to the project. 

You're of course free to have a 2.6 branch in your own repository and to 
continue that development if that's what you need. 

You can of course also distribute that work to the rest of the world, but 
there's a very practical problem with doing so if you call it GnuCash: You'd be 
delegating the support of your fork to the devs who are still working on 
GnuCash 3.x and towards GnuCash 4.x and they (we) don't have the resources to 
do that. The simple and obvious way to avoid that confusion would be for you to 
distribute your fork under a new name with its own "trade dress" and support 
mechanisms, hence my request.

As for building 3.x on Ubuntu 14.04, we run CI on Ubuntu 14.04 [3]. All of the 
needed packages are available except Googletest, for which you need only clone 
the source from GitHub and tell CMake where it is. You can use [3] as a setup 
script to quickly get a suitable build environment. If you need more help by 
all means ask.

Regards,
John Ralls



[1] https://bugzilla.gnome.org/show_bug.cgi?id=765846
[2] https://github.com/Gnucash/gnucash/pull/354
[3] https://github.com/Gnucash/gnucash/blob/maint/util/ci/ubuntu-14.04-docker
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


[GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

2018-05-27 Thread Christian Stimming
Dear John,

I did notice that the 2.6 branch was deleted (meaning: "maint" is now the 3.x 
branch), but I didn't understand the reasons and didn't see any discussion of 
this decision. I have some requirements which I can meet most easily by just 
continuing the 2.6 version of gnucash, but this in turn needed some occasional 
commits there. For example, I'm still running Ubuntu 14.04 for reasons beyond 
the scope of gnucash, and I haven't been able to build the 3.x branch on that 
machine because of missing packages. At the same time the 2.6 branch met all 
that I needed for everyday work, so I just stick to this.

Hence, I don't quite understand why there is such a strong requirement to 
prohibit specifically any further existence of a 2.6 branch, and why you use 
strong language to underline your point of view here. Also, it's a bit 
puzzeling to me why you suggest me of all people to "change the name and 
artwork" in case of a 2.6 branch - what have I missed here?? Where was the 
discussion that led to this decision? Where was the decision process, if this 
were the project's decision? Maybe some more liberality for other people and 
their different requirements might be more suitable on your side, before 
calling other people's requirements a "fantasy".

This particular pull request for the 2.6 branch showed up only one week after 
I created that branch. To me, this looks like there are still more people 
interested in such a branch. Of course, nothing new will happen there, but the 
interest still exists.

For this reason I propose to keep some old 2.6 branch still up and running in 
the gnucash repository. I would volunteer to act as an owner of that branch, 
in case this is needed, but on the other hand we didn't need any such 
designated branch maintainers for the most part. Further voices? objections? 
ideas? Thanks.

Regards,

Christian


Am Samstag, 26. Mai 2018, 10:50:32 schrieb John Ralls:
> Christian,
> 
> Your "branch-2.6" drew its first PR today, so I've deleted it to avoid any
> further confusion. Please consult with the rest of the team before you do
> anything like that again. If you'd like to maintain a 2.6 branch yourself
> you are of course free to fork GnuCash, though you should change the name
> and artwork to avoid confusion with the main project.
> 
> Regards,
> John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel