|
From: Mateusz L. <ma...@lo...> - 2015-03-25 16:03:12
|
On 25 March 2015 at 16:02, Vadim Zeitlin <vz...@ze...> wrote: > On Wed, 25 Mar 2015 10:19:27 +0100 Mateusz Loskot <ma...@lo...> wrote: > > ML> Having master checked out, I'm ready to submit patches back straight away. > > Sure, you can submit them -- but currently, i.e. when using git flow with > Github, they can't be merged easily (i.e. using the single button in the > web interface). This is exactly the problem which triggered this thread. I see. I admit, in most but very trivial cases, I try to avoid the button. In most cases, I have to merge the commit manually, or even cherry pick commits from PR, what's not uncommon. I have a feeling the GitHub web merge button fits the GitHub flow really, where merging a PR equals releasing new deployable/stable version. Anyway, I don't mind if we decide on a workflow that enables us to use the merge button. > ML> > SL> I'm a believer in the idea that the default branch should be a > ML> > stable SL> one. > ML> > > ML> > Notice that this is clearly not the case when not using git flow as > ML> > then all the development is done on master and stable releases branch off > ML> > it. And I do believe that most people have a clear understanding that > ML> > getting the latest master means you get the latest, but not necessarily the > ML> > most stable, version. > ML> > ML> Yes, it seems to be like that, in default GitHub arrangements. > ML> GitFlow overrides the role of master and if we do GitFlow, we do > ML> master == stable. > > It's even more rigid than this, it's so stable that it practically never > changes -- it's only updated when a release happens. Yes > Again, this is not > necessarily bad, but is definitely unusual, people expect to be able to > track changes as they happen if they pull from master, but with git flow > absolutely nothing happens in master. Sounds like you think of GitHub flow here. I suppose the traditional SVN-based workflow with master and release/X.Y maintenance branches may suffer from similar issues as GitFlow: - PR arrives - Travis CI is green - We (review of the code) say OK - We hit Merge button - PR makes it into master What if the PR delivers a bugfix that should update release/1.0? We have to manually merge that change to release/1.0 branch and publish release 1.0.1. We also have to merge it into the master. I see little use of the Merge button. Again, I believe, the Merge button fits the GitHub flow, doesn't it? > ML> My experience with maintaining and releasing SOCI bugfix releases > ML> revealed that one PITAs is > ML> 1. Collecting all PRs that qualify for a bugfix release > ML> - often fixes submitted in big PR bundles need to be cherry picked > ML> - often fixes submitted against develop need to be ported to master > ML> - often fixes do not receive any feedback or review, so unclear they are good > ML> - maintenance is no fun, but a time consuming boring task :) > > No workflow is going to help with the first and the last two points, of > course, but at least the second one is a pure annoyance due to an impedance > mismatch between git flow and Github and we could get rid of it. Yes, I agree. > ML> I chose GitFlow because it is well structured workflow that makes it > ML> no-brainer yet simple to follow, with one caveat...once you learn it :) > > Yes, I agree that it's not that difficult. But it's still more difficult > than alternatives. And, while it doesn't excuse my erroneous commits to > master, it's hard to keep track of different workflows when switching > between different projects, so simpler is always better. Sure. I didn't know before I tried. I tried, it worked, so I kept using it. I agree, after that experience, SOCI could benefit from simpler workflow. > ML> 3. Somewhere in between, we have traditional workflow known from, for > ML> example, Subversion: > ML> - master - here all development happens (submitted and merged from > ML> topic branches!) > ML> - release/X.Y.Z - maintenance branch > ML> - tags/X.Y.Z - tag > > This is indeed the most commonly used workflow IME. Notice that it's a > strict superset of (2). Yes. The only concern I have is, does it really support the Merge button? > ML> It seems, git makes release/X.Y.Z redundant > > The usual strategy is to have release/X.Y branch[es] and then X.Y.Z tags > on them. Of course, Major.Minor branch, without Micro/Patch number. I typed that to quick. > ML> My vote: > ML> 1. Drop GitFlow: +1 > ML> 2. New workflow: +1 for either 2 or 3 > > I don't think we can possibly use (2) because we do need 3.2 and 4.0 > branches, at least. I do prefer (3) to (1). Ok, if no objections, let's simplify to (3). Best regards, -- Mateusz Loskot, http://mateusz.loskot.net |