Fred,
On Fri, Nov 15, 2019 at 3:17 AM 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.
I agree. Now that I think about it that is closer to the model I have been following. I believe we should adopt it universally.
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.
Agreed.
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.
I doubt it would be that long, but point taken.
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.
I realize you're referring to me, Fred, no need to hide that fact. Say what you mean explicitly and plainly, I won't be insulted. I did fix most, if not all of your suggested changes where they made sense. The work done on NSOrderedSet shows this as well as other classes that I have contributed as of late. Some of the suggestions were made obsolete by other updates or were not needed such as changes to use fast enumeration.
Up until now I am one of the few who has been try to follow this process. I haven't seen an overabundance of PRs in the queue for either base or gui. There are 57 of them to date and many of them were created by myself and Frederick Seiffert and a few others. I would like to see more by other contributing members. What I don't like is people merging directly into master without creating a branch and without any oversight at all.
What I'm advocating is that we make this process universal and everyone and I do mean EVERYONE, including myself, needs to follow it to the letter.
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.
I have been a bit hasty as of late, but us "rogues" (or rather, heh, rogue) have contributed more in the past month than most have in a year. I have no issue following process or even defining it... as I am trying to do here.
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've been thinking about process more than most as evidenced by the fact that I was the one who brought the idea of imposing a process up in the first place.
Having worked for large corporations doing work in the Aerospace (NASA, Xcor) industry I know the value of process. In the case of when I worked for NASA it saved lives, literally.
As we say in the space industry: Blame is useless, Work the problem.
Yours, GC
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
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/