Re: [soci-users] Changing the default branch in the Github repository?

[Mateusz L. <ma...@lo...>]

On 25 March 2015 at 16:02, Vadim Zeitlin <vz...@ze...> wrote:
> On Wed, 25 Mar 2015 10:19:27 +0100 Mateusz Loskot <ma...@lo...> 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