On Sat, 22 Jul 2017 21:22:43 +0000 Andrew Williams <a...@andywilliams.me> said:
> 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. > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
