[E-devel] Git and branching

[Andrew Williams]

Hi eflers :)

So after thinking about issue management and planning milestones I thought
more about our source control. We currently have various different models
used but the bottom line is that it all hits master all the time which can
lead to less stability than ideal and also makes stabilisation windows
critical to enforce.

As a suggestion I think we should consider agreeing on a singlet branching
model and I'd recommend GitFlow (described quite well here
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow).
As well as being well organised there is a solid gitflow plugin that helps
to manage branches and workflows.

Bottom line: main development moves from "master" to "develop" and master
then remains the most recent release (always stable ;) ). Releases then are
created on a branch rather than being branched after release.

This correlates well with the proposed phab task management - a release
milestone branches off develop as we prepare to release like current
stabilisation. Big feature tasks branch off develop as a feature branch and
the task describing it can be marked resolved when it merges in. Hotfixes
merge into develop and master which makes it easier to ensure we don't
forget to backport fixes :).

Let me know what you think - it's worked quite well in previous groups but
I appreciate it may not for us and I expect there are a lot of experiences
here that could feed in :)

Happy weekend,
Andy

[Jonathan Aquilina]

Hi Andrew,

This is a good idea and I use it in my personal projects and highly
recommend it.

I woudl also like to propose another change at the phab level and to
onboard more devs. Libreoffice does things in an interest manner. They
classify the issues according to varying difficulty and then a new dev
can choose an issue according to their skill level and it helps them get
familiar with the code base. I think this is something we need to
implement as it would really help to get new devs familiar with the code
base, me included there.

---
Regards,

Jonathan Aquilina

Post by Andrew Williams
Hi eflers :)
So after thinking about issue management and planning milestones I thought
more about our source control. We currently have various different models
used but the bottom line is that it all hits master all the time which can
lead to less stability than ideal and also makes stabilisation windows
critical to enforce.
As a suggestion I think we should consider agreeing on a singlet branching
model and I'd recommend GitFlow (described quite well here
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow).
As well as being well organised there is a solid gitflow plugin that helps
to manage branches and workflows.
Bottom line: main development moves from "master" to "develop" and master
then remains the most recent release (always stable ;) ). Releases then are
created on a branch rather than being branched after release.
This correlates well with the proposed phab task management - a release
milestone branches off develop as we prepare to release like current
stabilisation. Big feature tasks branch off develop as a feature branch and
the task describing it can be marked resolved when it merges in. Hotfixes
merge into develop and master which makes it easier to ensure we don't
forget to backport fixes :).
Let me know what you think - it's worked quite well in previous groups but
I appreciate it may not for us and I expect there are a lot of experiences
here that could feed in :)
Happy weekend,
Andy

[Carsten Haitzler (The Rasterman)]

Post by Andrew Williams
Hi eflers :)
So after thinking about issue management and planning milestones I thought
more about our source control. We currently have various different models
used but the bottom line is that it all hits master all the time which can
lead to less stability than ideal and also makes stabilisation windows
critical to enforce.
As a suggestion I think we should consider agreeing on a singlet branching
model and I'd recommend GitFlow (described quite well here
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow).
As well as being well organised there is a solid gitflow plugin that helps
to manage branches and workflows.
Bottom line: main development moves from "master" to "develop" and master
then remains the most recent release (always stable ;) ). Releases then are
created on a branch rather than being branched after release.
This correlates well with the proposed phab task management - a release
milestone branches off develop as we prepare to release like current
stabilisation. Big feature tasks branch off develop as a feature branch and
the task describing it can be marked resolved when it merges in. Hotfixes
merge into develop and master which makes it easier to ensure we don't
forget to backport fixes :).
Let me know what you think - it's worked quite well in previous groups but
I appreciate it may not for us and I expect there are a lot of experiences
here that could feed in :)

this imho creates an unnecessary branch. if you want releases to branch off
they can just branch early BEFORE release from master, stabilized, then tag at
release. there's no need for a develop branch.

the point of stabilization in master is a social thing. it's trying to force
people into helping with stability and bugfixing. telling them "stop all your
feature work and help with this". it is MEANT to be an inconvenience to try and
engineer this kind of behaviour. i know it doesn't 100% work, but it does have
an effect. by just pushing all of that off into a branch, we'll basically lose
almost all of any positives we get from that.

developers have always been free to do major work in a branch. the downside of
this is no one knows it's happening until suddenly it all lands and all hell
breaks loose. sometimes it's necessary. sometimes it's not.

what is going to likely happen is everyone just switches to develop branch -
anyone wanting to track development is unaware of this and sees a stale master
branch and can't find where development is happening and we have really done
nothing positive - just added layers for hiding.

i like the simplicity of our model and that it pushes our current state of
development right as the first thing into the public with no extra work, and
that it tries to keep everyone on the same page as much as possible and tries
to pull everyone together for releases.

Post by Andrew Williams
Happy weekend,
Andy
--
http://andywilliams.me
http://ajwillia.ms
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel