On Tue, 17 Mar 2015 10:11:26 +0100 Sebastian Lauwers <sebastian.lauw...@gmail.com> wrote:
SL> I'd like to recommend /against/ this. There are two major implications: SL> SL> - All PRs will default against `develop`, which is what you're asking, SL> - Upon cloning, the checked-out branch will be `develop`. Hmm, I hadn't realized this, thanks for mentioning it. SL> There are a number of reasons why I'd recommend against this: SL> SL> - This can break a number of tools that automagically pull against the SL> repository; I'd expect all such tools to fetch all branches but it's not, of course, impossible, that some of them are broken... 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. 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. 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. 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. In fact, my personal favourite solution would be to keep master the default branch but drop git flow entirely. 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. 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. Regards, VZ
pgpoTDO4m9vCj.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
