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/
