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