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

[John Ralls]

> On Jun 2, 2018, at 1:10 AM, Geert Janssens <geert.gnucash at kobaltwit.be> 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 <geert.gnucash at kobaltwit.be>
>>>> 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