Hi, I'm really struggling with this thread - there is so much contradiction and a sprinkling of irony to boot...
Firstly the idea that GitFlow is only good if you force people to use it is plain nonsense - how would it become popular if people only used it when forced? Every team I've worked with in the last 5 years has found it to be beneficial and helps with visibility and stability. Along with the comment that it's only useful if you are paid to work this way and will not work I am open source community is an irony due to the number of people that are paid to work on efl - you can see it in the way that very few folk are around at the weekend these days and most contributors are focussed on specific projects. Regarding size comments in this thread there is a big contradiction. It's suggested that GitFlow will only be useful in larger teams and so not for us - and yet also that efl is too large to try this out with - not sure what to make of this. I don't think that it would be extra work for nothing. Partly because I don't see how this is extra work (bug fixes are supposed to go to 2 branches already and large features should be branched) and also because it does offer serious benefits - we do find that fixes are not properly backported (GitFlow ensures that fixes are always in next release as well as on develop) and also despite what we would wish master is not always stable. If folk are not familiar with how these benefits are ensured then I encourage you to check out the GitFlow extension for git - this is not just a branching model but a complete workflow with tooling that makes potentially tedious aspects simple. If there is education involved in workflows or practices then it seems better to go with a standard model than invent our own. As for the concern of branch divergence I think that is related to how much changes on a big branch without bringing master in - it's reasonable to expect long lived branches to merge in from their source branch to stay up to date with other changes and prepare for the resulting merge. Apologies I did not get a chance to respond to all the emails but there were too many hypothetical scenarios for me to make sense of. Thanks, Andy On Fri, 28 Jul 2017 at 10:24, Carsten Haitzler <[email protected]> wrote: > On Fri, 28 Jul 2017 09:00:39 +0200 Stefan Schmidt <[email protected]> > said: > > > Hello. > > > > Reading my mails from yesterday again I think one might be able to get > > the impression I actually want to shoot this idea down before it > > actually has a chance to proof itself. That is not what I wanted to > > bring across. :) > > well i am dubious of any advantages of it. i only see "more work, no gains > worth having for the work... and the only gain like having a continually > moving > "stable/release" branch that is not "current development" can be done in > reverse as i mentioned - just merge master INTO this branch... BUT what i > see > here is extra work for someone or everyone doing that cherry-picking > commits and > so on ... > > so i see how this can work when you PAY someone dedicated to doing this > task > and say "you must do this. it's your job". but not as an open source > project > though as you already mentioned in your replies. > > > I'm actually very much interested to get the workflow improved if there > > is a significant improvement that comes with it. As you can see from all > > these questions in my mails I have a lot of doubts that it would improve > > the situation. Maybe I just need to get educated. Hard to say. :) > > > > Another thing is that I am _very_ reluctant to try such a big change in > > efl first. If people want to move on with this we would need to see some > > examples in smaller community projects here to get a first idea. > > i'm with you on that for sure. > > > regards > > Stefan Schmidt > > > > > ------------------------------------------------------------------------------ > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
