+1 on all fronts. Thank you Adrien. > On Jun 3, 2018, at 10:02 AM, Adrien Monteleone > <adrien.montele...@lusfiber.net> 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 <jra...@ceridwen.us> wrote: >> >> >> >>> On Jun 2, 2018, at 2:05 PM, Christian Stimming <christ...@cstimming.de> >>> 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 > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
