Re: Gitflow proposal

[Richard Frith-Macdonald]

> On 15 Nov 2019, at 08:16, Fred Kiefer <address@hidden> wrote:
> 
> First off before I explain why I am strongly against Gitflow let me restate 
> that I advocate feature branches and pull requests. But I will come back to 
> that in the end.
> 
> A software workflow should match the organisation and purpose of a project 
> and the people that defined Gitflow are well aware of that. They describe 
> what sort of projects Gitflow is suited for. GNUstep does not meet that 
> criteria. Even in the place where I work we decided against Gitflow as it is 
> not well suited for our processes. I could go into details here but I believe 
> you are all able to follow the link below and read the description.
> 
> Also it won’t work. Nobody is getting payed to review pull requests on 
> GNUstep. If I started to write pull requests for GNUstep gun, they would be 
> sitting there for a year or so without anybody noticing.
> 
> The bigger problem is that even Gitflow won’t help us with our quality 
> issues. Over the last few months I have tried to provide comments to most of 
> the pull requests in the GNUstep repository. I do this a lot at work and 
> doing so comes naturally to me. Most of the developers react positive by 
> fixing the issues I point to. There is one exception and please look it up in 
> git to see the difference. In that case many of my comments did get ignored 
> others, where flagged as done although no change was made and sometimes 
> branches where merged even when travis reported them as broken or while I had 
> objected merging them. So even a workflow that enforces all this is of no use 
> in this case.
> 
> And it could be even worse. With Gitflow in place as a rule, Riccardo and I 
> could have been stopped from doing the emergency fixes we did last night to 
> get master compiling again (and not only for gcc, Riccardo's change must have 
> fixed compilation of clang as well). As long as we have rogue developers with 
> full permissions out there, we need ways to counteract.
> 
> So yes, let's use more branches and pull requests but especially those 
> developers that break the build. And if we ever manage to get them to follow 
> that rules we might start to think about more process

I broadly agree, though my reasoning may be a litte different.  I'm someone who 
finds it very hard (and very time consuming) to try to comment in ways that 
people won't find offensive, so a system where I'm called upon to comment more 
is very bad for me (and might end up putting other people off too);  with 
complex changes I also find it much more efficient to speak rather than 
exchanging comments (and people who know me will know how hard it is to get me 
to pick up the phone).

I rather like committing all small changes directly to trunk so that a maximum 
number of people in a small team will see them and fix/report errors.  I even 
feel it maks sense to do large/complex things in a branch and then merge the 
branch into trunk.
On the other hand, I sympathise with people who don't like to find trunk 
broken;  we clearly have people who want to keep up to date with trunk but 
don't want their builds to fail etc.  So I guess my ideal would be to mostly 
work on trunk but have automated build/test environments testing it and 
updating a another branch only to revisions where all the automated 
builds/tests have passed.  Non developers could then use that branch rather 
than trunk.