On 25 March 2015 at 16:02, Vadim Zeitlin <vz-s...@zeitlins.org> wrote: > On Wed, 25 Mar 2015 10:19:27 +0100 Mateusz Loskot <mate...@loskot.net> 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 ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ soci-users mailing list soci-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-users
