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. 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. 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. 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. 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. Most of all, I'd like to repeat that it seems obvious that git flow strength is its good support for multiple active releasable branches and frequent releases, neither of which is really needed for SOCI. ML> > Of course, this wouldn't help with your concerns as master would be ML> > exactly as [un]stable as develop is now. But if this helped SOCI ML> > development it would be still well worth it IMO. ML> ML> Ok, let's make it happen, unless there are objections from other ML> developers and contributors. ML> ML> To make it clearer what we are going to decide between, quick summary: ML> 1. On one hand, we have GitFlow - ML> http://nvie.com/posts/a-successful-git-branching-model/ ML> a well structured workflow that proved to be not as well known as I'd ML> assumed and too detailed for SOCI. This is the workflow I'd use if I had to make many releases. ML> 2. On the other hand, we have, so called, GitHub flow - ML> http://scottchacon.com/2011/08/31/github-flow.html ML> a kind of rolling release workflow, where master is always deployable ML> aka stable (as in GitFlow) This is the workflow I'd use if I didn't have to make any releases. 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). 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. 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). Regards, VZ
pgp7TOypOwowa.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
