Gitflow proposal
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 : > > 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
Re: Gitflow proposal
> On 15 Nov 2019, at 08:16, Fred Kiefer 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 I broadly agree, though my reasoning may be a litte different. I'm someone who finds it very hard (and very time consuming) to try to comment in ways that people won't find offensive, so a system where I'm called upon to comment more is very bad for me (and might end up putting other people off too); with complex changes I also find it much more efficient to speak rather than exchanging comments (and people who know me will know how hard it is to get me to pick up the phone). I rather like committing all small changes directly to trunk so that a maximum number of people in a small team will see them and fix/report errors. I even feel it maks sense to do large/complex things in a branch and then merge the branch into trunk. On the other hand, I sympathise with people who don't like to find trunk broken; we clearly have people who want to keep up to date with trunk but don't want their builds to fail etc. So I guess my ideal would be to mostly work on trunk but have automated build/test environments testing it and updating a another branch only to revisions where all the automated builds/tests have passed. Non developers could then use that branch rather than trunk.
Re: Gitflow proposal
FWIW: Both internally and for public projects, at $WORK we use feature branches and PRs, so I concur with Fred here. GitHub lets administrators commit changes without review, which we sometimes do for things like tweaks to comments and so on, but generally don't for anything involving a code change (or, if we do, at least wait until it's passed CI). Having a test suite that's parallelisable helps a lot here: The GitHub CI / Azure Pipelines executors are 4-core machines, so running the tests in parallel helps a lot with turn-around times. David On 15/11/2019 08:16, Fred Kiefer 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 : 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
Re: Gitflow proposal
Fred, On Fri, Nov 15, 2019 at 3:17 AM Fred Kiefer 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. > I agree. Now that I think about it that is closer to the model I have been following. I believe we should adopt it universally. > 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. > Agreed. 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. > I doubt it would be that long, but point taken. > 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. I realize you're referring to me, Fred, no need to hide that fact. Say what you mean explicitly and plainly, I won't be insulted. I did fix most, if not all of your suggested changes where they made sense. The work done on NSOrderedSet shows this as well as other classes that I have contributed as of late. Some of the suggestions were made obsolete by other updates or were not needed such as changes to use fast enumeration. Up until now I am one of the few who has been try to follow this process. I haven't seen an overabundance of PRs in the queue for either base or gui. There are 57 of them to date and many of them were created by myself and Frederick Seiffert and a few others. I would like to see more by other contributing members. What I don't like is people merging directly into master without creating a branch and without any oversight at all. What I'm advocating is that we make this process universal and everyone and I do mean EVERYONE, including myself, needs to follow it to the letter. 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. > I have been a bit hasty as of late, but us "rogues" (or rather, heh, rogue) have contributed more in the past month than most have in a year. I have no issue following process or even defining it... as I am trying to do here. 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. > I've been thinking about process more than most as evidenced by the fact that I was the one who brought the idea of imposing a process up in the first place. Having worked for large corporations doing work in the Aerospace (NASA, Xcor) industry I know the value of process. In the case of when I worked for NASA it saved lives, literally. As we say in the space industry: Blame is useless, Work the problem. Yours, GC Fred > > > Am 15.11.2019 um 05:30 schrieb Gregory Casamento < > greg.casame...@gmail.com>: > > > > 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 > >
Re: Gitflow proposal
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
Re: Gitflow proposal
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 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/
Re: Gitflow proposal
I think Fred hits the major points quite well, in all the GNU projects i've ever worked on besides GNUstep even maintainers post patches for review for the benefit of other maintainers. 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. 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... 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... On Fri, Nov 15, 2019 at 8:16 AM Fred Kiefer 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 : > > > > 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 > >
Re: Gitflow proposal
Matt, On Fri, Nov 15, 2019 at 9:08 AM Matt Rice 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 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 < > greg.casame...@gmail.com>: > > > > > > 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 mitiga
Re: Gitflow proposal
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 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 > wrote: > >> >> Matt, >> >> On Fri, Nov 15, 2019 at 9:08 AM Matt Rice 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 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 < >>> greg.casame...@gmail.com>: >>> > > >>> > > 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 y
Re: Gitflow proposal
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 wrote: > > Matt, > > On Fri, Nov 15, 2019 at 9:08 AM Matt Rice 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 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 < >> greg.casame...@gmail.com>: >> > > >> > > 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/comp
