Hi, An interesting point. I guess I figure there is something between massive merges and the alternative of breaking master. Isn't it fair to say that we shouldn't ever be breaking master even if we're doing cool new stuff? (yes, I know I have done it too, it's the way things are just now).
When I've seen companies working off master they inevitably have to come up with lots of new rules like "no pushes on a Friday afternoon", "WiP must be handed over before a day off" or "tests will be run on the server in a pre-push hook to validate your work" to maintain their base branch. These all seem like anti-patterns for a great team... If "all hell breaks loose" then have we not missed something else in our communication? Andy On Wed, 26 Jul 2017 at 16:19 Gustavo Sverzut Barbieri <barbi...@gmail.com> wrote: > 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 <+55%2016%2099354-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 > -- 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
