On Wed, 26 Jul 2017 22:36:53 +0000 Andrew Williams <a...@andywilliams.me> said:
> Hi, > > I understand the reasoning behind the social convention of the master > stabilisation period but what seems to be evolving as git standard is that > master should always be stable / releasable - not stable, but something > that can be relied upon. From where we are the equivalent is not to push > stabilisation into a branch but to have it more release-ready by default. if it's is trendy or not... it's not how we do things... (have a always-read-to-release branch). BUT i do believe master should be stable and usable at all times. don't make it not so by explicit decision or design. you could just have a "release" branch FROM which each stable release is branched. i don't see why we need to move to a develop branch. then the release manager can pull from master to release (as opposed from develop to master in your model). but that's up to the release manager... if he finds this easier to cut releases this way... then great. we don't need to redesign our workflow to do THAT... unless you want everyone doing this pull to a release/stable branch and then everyone has to change. but it will lead to more problems. which features were and were not cherry-picked from "develop" (if its called develop or it's master is irrelevant EXCEPT in that master is what git shows the world as the DEFAULT). i believe this is going to raise the workload for the release manager and./or for developers as they have to both commit AND then remember to merge that commit or series into "release". things will be forgotten. releases will end up missing things and break as they get change A but miss change B which subtly interacts with change A to make thins work right... i smell a world of hurt with the model you propose. releases and what developers work on/use will NOT be on the same page. and that is a recipe for pain. getting as many people on the same page as possible is, IMHO and experience, the best you can do. the rest can't be solved by branches, processes or tools. it's just being careful. being there to fix your code when it goes wrong. it's responsibility and communication. > The concern about people not sharing what is being worked on and large > changes coming out of nowhere are, in my opinion, a communications issue > and not a source control issue. Having partially completed features on > master or changes that are "temporary" awaiting the rest of the work is > worse than having more branches. I don't mean to say that branches should > be needed for every change - that is why the develop branch in GitFlow > exists to allow the small features and fixes to work on the mainline > without affecting the stability of master. > > Developers may indeed switch everything to develop - but I don't see how then why not just keep working in master? why does SWITCHING help at all? if then all developers switch... the only thing you changed was what the DEFAULT thing people see is when they do git clone without any extra effort. that's all. and i think we want people to see the current state of development by default. we have release tarballs (intended to be packages) to STABLE RELEASES. for the few people like packagers who want to track a specific stable branch to package from, we have branches. IMHO very few people want to or need to do that. and if you want a "release" or "current-stable" or whatever branch (that you propose should be master) then that can be created too. it doesn't involve anyone changing any workflow from today except the release manager if that is their responsibility to merge then from development (currently master) to that. of course if only one person does this it's going to be a mess. it's going to add a lot of work, tracking overhead etc. and it's going to slow us down, increase our workload, etc. ... if every developer has to do it themselves it adds this work and changes to workflow to everyone. as above... i smell disaster here. > that leads to confused newcomers. A standard tenet of git is that you don't > commit directly to master and branching is part of the workflow unlike CVS > or SVN. This allows easy tracking of 2 different targets: Latest stable > version (master) and latest completed features (develop) and work in > progress is elsewhere. tenet or not... this actually sounds much more like a religious argument than a practical one. people have done just this (see gustavo's mail). the vast majority of the time it has lead to much more hell breaking loose. that's my experience. :) > Whilst I can't argue with the simplicity of our branching model I don't > know that I completely agree that stopping for a month every release is > indicative of a good process... you can continue doing work in a branch of your own if you want. if your issue really is with the stopping... let's talk about that. :) the point of the stop is to push/encourage you to help to testing, debugging, cleaning, stabilization and to help the release manager get the code into shape for a release. like a kitchen in a restaurant. you try and clean as you go but it's only partly effective. you will leave a bit of mess here and there. at the end of the night when the cooking stops... the cleaning begins so the kitchen is clean and ready the next day. we could just have all the cooks quite and go home then 1 poor janitor has to do it all. we're asking all the cooks to stay around and help clean things up. many hands make light work. :) i use these periods to get stuck into some of the more annoying background bugs that i have ignored during development and code cleaning (coverity) and some tickets. everyone probably tackles different bits, but i think it's a good thing. if you WANT to you can "go home and not help clean the kitchen". sometimes you're tired and want to... who knows. if you want to go home and cook some more, you can... create a branch for that. merge it when we unfreeze. beware that this may cause hell to break loose if you're not careful when the dump happens :) so summary: you present an alternate workflow. this is interesting. i don't see why master HAS to be "stable and releasable". it's just a question of what the default thing you show to the world is (you show master by default). if we just change this... why does it have to be master that is stable. we could have "release" for that. but then come in the questions of who merges to release. i smell much more work here and things will fall through the gaps and that will ultimately lead to a worse situation that we have today. > Andy > > On Sun, 23 Jul 2017 at 03:32 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 > > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- 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
