So from my reading it seems we don't have a clear agreement here? I'd
really prefer to defer this decision to Mateusz.
Thanks,
Aleksander
On Tue, Mar 17, 2015 at 6:13 AM, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
