On Fri 15 Nov 2019 at 09:45, Ivan Vučica <address@hidden> 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 <address@hidden> wrote:Matt,On Fri, Nov 15, 2019 at 9:08 AM Matt Rice <address@hidden> 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...OkThis adds a bit of delay to the whole process however not entirelyunbounded 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 <address@hidden> 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 <address@hidden>:
> >
> > 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