> 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