Gitflow proposal

[Fred Kiefer]

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.

Fred

> Am 15.11.2019 um 05:30 schrieb Gregory Casamento <address@hidden>:
> 
> Guys,
> 
> I must say this.  I have been trying to, in general, hold myself to doing 
> this rather formally up until recently.  I admit that I have been more 
> directly pushing things in as of late.
> 
> Since, as you say, this could have been avoided by doing PRs... which it 
> could have.  Should we not, as an project, move to this model?  It's known as 
> gitflow and it's what I was following when I would create a branch with large 
> changes and then have it reviewed by yourself and others before merging.   
> This would slow some development down, but it would have the effect of 
> keeping master in a condition where it always builds and is always releasable 
> (which should always be the case).
> 
> Here is a link, for reference: 
> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> 
> Some might argue that this should only be done with large teams, but I used 
> this process on a small team when I worked at a company known as customink 
> where we only had 4 people and it still helped things go very smoothly.
> 
> This is the process I've been trying to adhere to.  I would advocate that, if 
> PRs could have prevented this then, perhaps, we should all move to it.  I had 
> a discussion with Riccardo where he thought this process was too much and was 
> silly and that merging to the master branch directly is always the best way 
> to go.   That's precisely what caused this.   We can make all of the 
> arguments that "a focused developer wouldn't make these mistakes" but that's 
> BS.  Process is here to prevent mistakes or to mitigate them.
> 
> I disagree with Riccardo's position wholeheartedly.   A more controlled and 
> disciplined approach should be adopted and we should stick to it.
> 
> Any thoughts?
> 
> Yours, GC