Re: Gitflow proposal

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:
> 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.

"gun" ??? git is a gun? :)

But I agree, there are no paid reviewers here. Theoretically, 
maintainers of every package should do that, but it is too much to ask.
Even at work, people getting in charge of code reviews of pullr equest 
can get a high level of stress!

As Richard stated in another mail - complex comments are long to write 
and discussions inside comments can be even worse than per mail, 
chat.... or phone!

> 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.

This is precious work, Fred. One thing though: I really hate hoe 
comments are managed. I don't have a clear list of comments to review, 
re-read, etc. They can be both in a PR (which is easier) or also on just 
a commit, in that case with the github UI is a mess. I loose track, so I 
actually rely on the emails I get for the comments and link-open to find 
the reference on the code again. So it is a complicated way to handle 
things.

Generally speaking, however, this setup has several advantages in 
control, but is timeconsuming.

At work, I think a full set up gets very bureaucratic.

# stable trunk
-- "devel" trunk wtih merges of all the feature branches
---- > bug fix branch
---- > feature branch 1
---- > feature branch 2
....

but, since here we don't work with a whole load of sub-contractors and 
developers, I'd prefer something more simple!


> 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.

Branches should be used for everything which is a longer-running changes 
should be a branch and pulled together.

Riccardo