I second raster here. For years I pushed for more stable master, development in branches. While I tend to work in a branch myself, and test it before merging... what happens is that once you merge, hell breaks loose... so I tend to land and reserve some time to track reports on IRC/mailing list... as users and other developers tend to have use cases I couldn't anticipate.
asking people to test your branch before landed usually doesn't have the same "test effect"... you can ping people many times, yet it won't get enough testing. so after some years I had to agree with raster and the positive side of "break master, but fix it quickly" On Sat, Jul 22, 2017 at 11:32 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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 -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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
