On 17 March 2015 at 14:13, Vadim Zeitlin <vz-s...@zeitlins.org> wrote: > On Tue, 17 Mar 2015 10:11:26 +0100 Sebastian Lauwers > <sebastian.lauw...@gmail.com> wrote: > > SL> - Most users who just want the source code don't necessarily need to > SL> know what the development workflow is. As soon as you start tracking > SL> the `develop` branch, you know that you're going to be using fairly > SL> specific user scenarios. I'd wager that there are a lot more SOCI > SL> users than developers. > > This is clearly true, although we can probably assume that only the > "advanced" users get their sources from git.
I often checkout libraries from git to try out, see if they build in my environment, and it's not uncommon I need to update build scripts or apply small fixes. Having master checked out, I'm ready to submit patches back straight away. > SL> I'm a believer in the idea that the default branch should be a stable > SL> one. > > Notice that this is clearly _not_ the case when _not_ using git flow as > then all the development is done on master and stable releases branch off > it. And I do believe that most people have a clear understanding that > getting the latest master means you get the latest, but not necessarily the > most stable, version. Yes, it seems to be like that, in default GitHub arrangements. GitFlow overrides the role of master and if we do GitFlow, we do master == stable. Assuming we stick to GitFlow, I'd prefer to not to make any variations to that. I'm not attached to GitFlow. I can drop it. Let's propose and get all devs agree on simpler/better/preferred workflow. Until that happens, I'd suggest with stick to GitFlow. > SL> I'm sure there's a greasemonkey script somewhere that would allow you > SL> to automagically select `develop` rather than `master`. > > This is not the only problem though. Most of the existing PRs (I was > looking over them recently trying to pick all uncontroversial ones and > apply them) were made against master and not develop too. > And I don't see this changing: when you clone a repository, it's natural to > do your changes > in master. So, basically, this means that it will continue to be impossible > to merge PRs easily. Yes, I noticed this issue too. > And this is IMO a bigger problem, SOCI development is > already almost stalled and not applying PRs quickly is not going to help > get it moving faster again. I haven't been able to find time to finally clear the 3.2.3 release off my table. That keeps me away from doing anything new regarding SOCI 4. My experience with maintaining and releasing SOCI bugfix releases revealed that one PITAs is 1. Collecting all PRs that qualify for a bugfix release - often fixes submitted in big PR bundles need to be cherry picked - often fixes submitted against develop need to be ported to master - often fixes do not receive any feedback or review, so unclear they are good - maintenance is no fun, but a time consuming boring task :) > In fact, my personal favourite solution would be to keep master the > default branch but drop git flow entirely. That's a clear & fair request. As I mentioned above, I'm not attached. > It's probably a good workflow > for managing a team of many developers and a project with many releases, > but neither of these criteria applies to SOCI: there are few developers and > even fewer releases. Using the traditional master-and-release-branches > workflow is simpler and would IMHO be quite enough for this project. I chose GitFlow because it is well structured workflow that makes it no-brainer yet simple to follow, with one caveat...once you learn it :) > Of course, this wouldn't help with your concerns as master would be > exactly as [un]stable as develop is now. But if this helped SOCI > development it would be still well worth it IMO. Ok, let's make it happen, unless there are objections from other developers and contributors. To make it clearer what we are going to decide between, quick summary: 1. On one hand, we have GitFlow - http://nvie.com/posts/a-successful-git-branching-model/ a well structured workflow that proved to be not as well known as I'd assumed and too detailed for SOCI. 2. On the other hand, we have, so called, GitHub flow - http://scottchacon.com/2011/08/31/github-flow.html a kind of rolling release workflow, where master is always deployable aka stable (as in GitFlow) 3. Somewhere in between, we have traditional workflow known from, for example, Subversion: - master - here all development happens (submitted and merged from *topic* branches!) - release/X.Y.Z - maintenance branch - tags/X.Y.Z - tag It seems, git makes release/X.Y.Z redundant, because if hotfix arrives, we can always create a branch from the tag, then release and tag with new version (along with merging into master, of course). Now, the option 1. proved to be too complicated for us. The option 2, to me personally, sounds compelling as it seems to remove most of the maintenance and releasing hassle - a PR arrives, it's reviewed and tested, then either refused or merged to master. If merged, it's released - the master is a release. But, are we happy with no-version release? The option 3 has the advantage of structure, is well known traditional workflow and has versioned releases. My vote: 1. Drop GitFlow: +1 2. New workflow: +1 for either 2 or 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
