Riccardo,
What Fred is advocating is simply to create a feature branch and merge it
back into master when ready. Gitflow includes an extra develop branch
which we don't need.
I agree with Fred that feature branches would help things a lot so long as
we all follow it. It's not too heavyweight. It makes sure that everything
gets reviewed.
It is simply....
master ----------------------->
| /\
\_____ feature branch _/
On the feature branch we can do a PR and a review before things are merged
as well as implement tests to run under CI.
GC
On Fri, Nov 15, 2019 at 5:55 AM Riccardo Mottola <riccardo.mott...@libero.it>
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
>
>
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/
