Re: Gitflow proposal

On Fri, Nov 15, 2019 at 5:55 AM Riccardo Mottola <address@hidden> wrote:

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

From:	Gregory Casamento
Subject:	Re: Gitflow proposal
Date:	Fri, 15 Nov 2019 06:04:08 -0500