Oh, also, in GNUstep’s case, honestly, I’m not too keen on making reviews mandatory even in general case — just a strongly encouraged practice.
On Fri 15 Nov 2019 at 09:45, Ivan Vučica <[email protected]> wrote: > I might be incorrectly following the discussion. > > Reviews with the exception for quick fixes — yes. > > Someone drew a graph of stable, which is forked into dev branch, which is > forked into individual feature branches. FWIW I personally like the PR > model, and pulling incoming PRs into master; if there is a need for stable > branches, I’d keep separate stable branches. Or not even branches: take the > tag for previous release (let’s say 2.45.0), cherrypick the fix, tag the > new release (2.45.1). > > Master is, to me, the “unstable” beast. Stable branches are just that. To > my memory we haven’t really had a need for stable branches, but... > > On Fri 15 Nov 2019 at 09:40, Gregory Casamento <[email protected]> > wrote: > >> >> Matt, >> >> On Fri, Nov 15, 2019 at 9:08 AM Matt Rice <[email protected]> wrote: >> >>> I think Fred hits the major points quite well, >>> >> >> I agree. >> >> >>> in all the GNU projects i've ever worked on besides GNUstep even >>> maintainers post patches for review for the benefit of other >>> maintainers. >> >> >> Of course. >> >> Certain things are disqualified from this, such as >>> fixing typos, unbreaking master either by reverting or fixing the >>> commit... Things which could be justified as being obvious changes. >>> >> >> Yes, quick fixes are okay to go right to master. >> >> Generally when patches are posted, and do not receive review a >>> maintainer (usually the author but i don't feel like ruling it out), >>> can give a heads up that they intend to commit the patch in the near >>> future within some reasonable timeframe... >> >> >> Ok >> >>> This adds a bit of delay to the whole process however not entirely >> >> unbounded nor too rigid, >>> but gives others their say. Personally i would say the lack of any >>> review process was a major factor in my decision to stop >>> contributing... >>> >>> >> Understandable. >> >> >> >>> On Fri, Nov 15, 2019 at 8:16 AM Fred Kiefer <[email protected]> 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. >>> > >>> > 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 < >>> [email protected]>: >>> > > >>> > > 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/ >> > -- > Sent from Gmail Mobile > -- Sent from Gmail Mobile
