Re: [PHP-DEV] Adopt GitFlow process
On Mon, Mar 26, 2012 at 12:03 PM, Alexey Shein con...@gmail.com wrote: 26 марта 2012 г. 4:30 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! Main problem is that our current workflow doesn't allow branch-only changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go there. Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an example? I can see it if the code had substantial change there so bugfix no longer applies. In this case, I would try the merge, see it fail and resolve it as all ours. It shouldn't take longer than 10 mins. Though it you have ideas how to improve that without disrupting the rest of the process and the common use case, you are welcome. For example this commit http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4 by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will describe better. It was then accidentally merged into PHP-5.4 by Hannes (which broke something in PHP-5.4) when he was merging his own changes which merge made a lot of confusion. We should really deal with this problem first before diving further, since it will have great impact on the whole working process with git. If we can live with simple git merge - it would be simply awesome. 1) use cherry-picking in one repo. This has big downside (as dsp pointed) that we can't use git annotate, bisect and other commands assuming that commit is introduced in repository only once. bisect is a bit weird now btw, since it seems to be a bit confused by 5.3-5.4 merge that happened not when it thinks it did - so if you try to bisect changes in 5.4 branch only, you will get some very old changes in. You can quickly go through that, marking them as good, but still not ideal situation. Yep, already tried bisect and it doesn't seem work good at least for php-5.3 branch. Okay, since I'm not too familiar with release process, assume following (please, correct me if I'm wrong): * PHP 5.3 can't have features, only bugfixes True. * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and master) and bugfixes that should stay only in PHP-5.3 Not entirely true - 5.3 code can have bugfixes that aren't merged up, but that would not be the common case. Example - bugfix regarding magic quotes or safe mode, which are not in 5.4. So it's still possible to have not-merged up bugfixes. That means that we should take that into account. I'm just trying to figure out our needs to better understand what needs to be done then. * PHP-5.4 and master can have bugfixes and features that are merged upstream (master) and bugfixes/features that should stay only in current branch 5.4-only fixes very unlikely, as master and 5.4 are very close today. If we ever do big changes in master this is a possibility, as described above, but still won't be a common case - unless we rewrite our engine completely, which doesn't seem to be likely. * All branches are have regular releases True, except for master. In gitflow you have 4 branches: * master - contains only production ready releases, nobody commits here directly * develop - main development branch, all work usually is get merged here * feature/name - feature/bugfix branches for separate bugfixes and features. Merged into develop. * hotfix/name - same that feature branches but is urgent and is always merged into master *and* develop. For example, when security release is issued, this fix should go into release and into main development branch. * release/name - pre-release stability branches, for bug-fixes only. Merged into develop and master (making a new release). When you have a release branch, you can't commit into develop (so hotfixes go here too, if we have release branch). I don't like that can't commit into thing - the main advantage of git as I see it that you can manage release branch and dev/stable branches separately and not have the situation of asking people to sit on their code for 2 months while release is being stabilized. Sorry, I messed this up. You actually can commit into the develop, new features go there, while bugfixes should go in release branch. If you want you can merge release branch into develop anytime you want, it's just should be done at least once when release branch is closed. Make a bugfix in 5.3 $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 $ git flow feature finish -k bugfix 5.3-develop Bugfix get merged into 5.3-develop - this should be implemented since gitflow supports only 1 develop branch for now. -k says to keep branch after finish, since we'll need it to merge upstream Why would we need bugfix branch in our repo here? I would say keep it in your own fork, test it, show it off, get it ready - then merge
Re: [PHP-DEV] Adopt GitFlow process
26 марта 2012 г. 4:30 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! Main problem is that our current workflow doesn't allow branch-only changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go there. Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an example? I can see it if the code had substantial change there so bugfix no longer applies. In this case, I would try the merge, see it fail and resolve it as all ours. It shouldn't take longer than 10 mins. Though it you have ideas how to improve that without disrupting the rest of the process and the common use case, you are welcome. For example this commit http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4 by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will describe better. It was then accidentally merged into PHP-5.4 by Hannes (which broke something in PHP-5.4) when he was merging his own changes which merge made a lot of confusion. We should really deal with this problem first before diving further, since it will have great impact on the whole working process with git. If we can live with simple git merge - it would be simply awesome. 1) use cherry-picking in one repo. This has big downside (as dsp pointed) that we can't use git annotate, bisect and other commands assuming that commit is introduced in repository only once. bisect is a bit weird now btw, since it seems to be a bit confused by 5.3-5.4 merge that happened not when it thinks it did - so if you try to bisect changes in 5.4 branch only, you will get some very old changes in. You can quickly go through that, marking them as good, but still not ideal situation. Yep, already tried bisect and it doesn't seem work good at least for php-5.3 branch. Okay, since I'm not too familiar with release process, assume following (please, correct me if I'm wrong): * PHP 5.3 can't have features, only bugfixes True. * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and master) and bugfixes that should stay only in PHP-5.3 Not entirely true - 5.3 code can have bugfixes that aren't merged up, but that would not be the common case. Example - bugfix regarding magic quotes or safe mode, which are not in 5.4. So it's still possible to have not-merged up bugfixes. That means that we should take that into account. I'm just trying to figure out our needs to better understand what needs to be done then. * PHP-5.4 and master can have bugfixes and features that are merged upstream (master) and bugfixes/features that should stay only in current branch 5.4-only fixes very unlikely, as master and 5.4 are very close today. If we ever do big changes in master this is a possibility, as described above, but still won't be a common case - unless we rewrite our engine completely, which doesn't seem to be likely. * All branches are have regular releases True, except for master. In gitflow you have 4 branches: * master - contains only production ready releases, nobody commits here directly * develop - main development branch, all work usually is get merged here * feature/name - feature/bugfix branches for separate bugfixes and features. Merged into develop. * hotfix/name - same that feature branches but is urgent and is always merged into master *and* develop. For example, when security release is issued, this fix should go into release and into main development branch. * release/name - pre-release stability branches, for bug-fixes only. Merged into develop and master (making a new release). When you have a release branch, you can't commit into develop (so hotfixes go here too, if we have release branch). I don't like that can't commit into thing - the main advantage of git as I see it that you can manage release branch and dev/stable branches separately and not have the situation of asking people to sit on their code for 2 months while release is being stabilized. Sorry, I messed this up. You actually can commit into the develop, new features go there, while bugfixes should go in release branch. If you want you can merge release branch into develop anytime you want, it's just should be done at least once when release branch is closed. Make a bugfix in 5.3 $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 $ git flow feature finish -k bugfix 5.3-develop Bugfix get merged into 5.3-develop - this should be implemented since gitflow supports only 1 develop branch for now. -k says to keep branch after finish, since we'll need it to merge upstream Why would we need bugfix branch in our repo here? I would say keep it in your own fork, test it, show it off, get it ready - then merge it into php repo. What is the reason for us to keep halfbaked fix branches in our repo? Merge bugfix from 5.3 repo to 5.4 First, rebase branch against 5.4 $ git
[PHP-DEV] Adopt GitFlow process
Hi, internals! There was a discussion recently on IRC that our current git working process is not perfect (especially about keeping one branch-only bugfixes) so that's a suggestion to use (and modify to better suit our needs) nvie's gitflow process and git-flow tool he developed to ease the process. If you're not yet familiar what is that, please read his wonderful article http://nvie.com/posts/a-successful-git-branching-model/ another wonderful article about the gitflow tool http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ go to git-flow project on github: https://github.com/nvie/gitflow watch video tutorials about gitflow http://buildamodule.com/video/change-management-and-version-control-deploying-releases-features-and-fixes-with-git-how-to-use-a-scalable-git-branching-model-called-gitflow http://vimeo.com/16018419 http://codesherpas.com/screencasts/on_the_path_gitflow.mov Personally, I see migration from current setup that way so each release branch (PHP-5.3, PHP-5.4 and master) becomes a separate repository with adopted gitflow model (although it should be thought through more carefully). What do you think about that? -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adopt GitFlow process
Hi! There was a discussion recently on IRC that our current git working process is not perfect (especially about keeping one branch-only bugfixes) so that's a One thing with discussions on IRC is that nobody except those present there can neither participate nor know what was talked about. And since we have timezone differences and other stuff going on in our lives, that means, on my estimate, a substantial percentage of the people here wouldn't know anything about what was discussed. Thus, it would be useful to explain what exactly is the problem we are talking about. If you're not yet familiar what is that, please read his wonderful article http://nvie.com/posts/a-successful-git-branching-model/ another wonderful article about the gitflow tool http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ This is a nice process, however I'm not sure how it could apply to PHP. Could you outline what will be done in this case when we have: 1. A bugfix for 5.3 2. A bugfix for 5.4 3. A feature addition for 5.4 4. A release of 5.3.x 5. A release of 5.4.x 6. A release of 5.5 and 5.5.x Also, what would happen if bugfix/feature is contributed via github pull? Personally, I see migration from current setup that way so each release branch (PHP-5.3, PHP-5.4 and master) becomes a separate repository with adopted gitflow model (although it should be thought through more carefully). What do you think about that? I do not think it makes sense to keep the code in separate repos, given that about 90% of the code is the same. It also will make much harder to accept outside contribution - I'm not sure how easy would it be to merge a patch into three repos from one pull req. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adopt GitFlow process
On Sun, Mar 25, 2012 at 2:04 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! There was a discussion recently on IRC that our current git working process is not perfect (especially about keeping one branch-only bugfixes) so that's a One thing with discussions on IRC is that nobody except those present there can neither participate nor know what was talked about. And since we have timezone differences and other stuff going on in our lives, that means, on my estimate, a substantial percentage of the people here wouldn't know anything about what was discussed. Thus, it would be useful to explain what exactly is the problem we are talking about. +1 If you're not yet familiar what is that, please read his wonderful article http://nvie.com/posts/a-successful-git-branching-model/ another wonderful article about the gitflow tool http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ This is a nice process, however I'm not sure how it could apply to PHP. Could you outline what will be done in this case when we have: 1. A bugfix for 5.3 2. A bugfix for 5.4 3. A feature addition for 5.4 4. A release of 5.3.x 5. A release of 5.4.x 6. A release of 5.5 and 5.5.x Also, what would happen if bugfix/feature is contributed via github pull? I'm also a strong proponent of NVIE's branching model. We'd probably have to modify it to suit PHP's exact needs, but in principle I very much advocate it as it actually takes full advantage of Git's branching strengths over Subversion. Personally, I see migration from current setup that way so each release branch (PHP-5.3, PHP-5.4 and master) becomes a separate repository with adopted gitflow model (although it should be thought through more carefully). What do you think about that? I do not think it makes sense to keep the code in separate repos, given that about 90% of the code is the same. It also will make much harder to accept outside contribution - I'm not sure how easy would it be to merge a patch into three repos from one pull req. Agreed. Breaking PHP into separate repos would carry a lot of implications that make me uneasy. Instead, I think it would be better to modify the NVIE workflow model to bridge the two branches (basically, it would be like linking 2 develop and 2 master branches somehow) in parallel on the same repo. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adopt GitFlow process
26 марта 2012 г. 2:04 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! There was a discussion recently on IRC that our current git working process is not perfect (especially about keeping one branch-only bugfixes) so that's a One thing with discussions on IRC is that nobody except those present there can neither participate nor know what was talked about. And since we have timezone differences and other stuff going on in our lives, that means, on my estimate, a substantial percentage of the people here wouldn't know anything about what was discussed. Thus, it would be useful to explain what exactly is the problem we are talking about. Main problem is that our current workflow doesn't allow branch-only changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go there. After some thinking it seems that GitFlow doesn't solve this problem since it's based on merging :), so let's postpone its presence here for a while. What can we do here: 1) use cherry-picking in one repo. This has big downside (as dsp pointed) that we can't use git annotate, bisect and other commands assuming that commit is introduced in repository only once. 2) Simplify code that way so we won't need one-branch only changes, can't say anything concrete here since I'm not familiar with PHP internals at all. We still need a better solution here. If you're not yet familiar what is that, please read his wonderful article http://nvie.com/posts/a-successful-git-branching-model/ another wonderful article about the gitflow tool http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ This is a nice process, however I'm not sure how it could apply to PHP. Could you outline what will be done in this case when we have: 1. A bugfix for 5.3 Okay, since I'm not too familiar with release process, assume following (please, correct me if I'm wrong): * PHP 5.3 can't have features, only bugfixes * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and master) and bugfixes that should stay only in PHP-5.3 * PHP-5.4 and master can have bugfixes and features that are merged upstream (master) and bugfixes/features that should stay only in current branch * All branches are have regular releases Advantage of git flow is that your development process becomes more straightforward, you can concentrate on development then on merging bureaucracy. In gitflow you have 4 branches: * master - contains only production ready releases, nobody commits here directly * develop - main development branch, all work usually is get merged here * feature/name - feature/bugfix branches for separate bugfixes and features. Merged into develop. * hotfix/name - same that feature branches but is urgent and is always merged into master *and* develop. For example, when security release is issued, this fix should go into release and into main development branch. * release/name - pre-release stability branches, for bug-fixes only. Merged into develop and master (making a new release). When you have a release branch, you can't commit into develop (so hotfixes go here too, if we have release branch). That's canonical git-flow. We obviously will need several master and develop branches, since PHP release branches need own development and can't be merged in each other. That's not yet implemented and needs to be done in git-flow. So you want to make a bugfix in 5.3 that will be merged upstream Make a bugfix in 5.3 $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 hack ... check ... test $ git add git commit $ git flow feature finish -k bugfix 5.3-develop Bugfix get merged into 5.3-develop - this should be implemented since gitflow supports only 1 develop branch for now. -k says to keep branch after finish, since we'll need it to merge upstream Merge bugfix from 5.3 repo to 5.4 First, rebase branch against 5.4 $ git rebase --onto develop-5.4 bugfix~num bugfix Where num is number of commits in your branch. I know it sucks, but that's how it works :) Or you can git cherry-pick each commit, (simpler solution anyone?). Now your bugfix branch is rebased against 5.4-develop and ready to be merged $ git flow feature finish -k bugfix 5.4-develop Repeat the same for master: $ git rebase --onto develop-master bugfix~num bugfix $ git flow feature finish -k bugfix master-develop Push changes: $ git push 2. A bugfix for 5.4 3. A feature addition for 5.4 Same as above. Since all work is done in branches there's no difference between bugfixes and features. 4. A release of 5.3.x $ git flow release start 5.3.58 bump version number now prepare NEWS, UPGRADING and all that stuff $ git flow release publish 5.3.58 # publish (push to remote repo) release-branch. It's not finished yet! When release is ready you do $ git flow release finish 5.3.58 Release get merged into 5.3-develop and 5.3-master, creating a tag 5.3.58 in 5.3-master 5. A
Re: [PHP-DEV] Adopt GitFlow process
Hi! Main problem is that our current workflow doesn't allow branch-only changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go there. Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an example? I can see it if the code had substantial change there so bugfix no longer applies. In this case, I would try the merge, see it fail and resolve it as all ours. It shouldn't take longer than 10 mins. Though it you have ideas how to improve that without disrupting the rest of the process and the common use case, you are welcome. 1) use cherry-picking in one repo. This has big downside (as dsp pointed) that we can't use git annotate, bisect and other commands assuming that commit is introduced in repository only once. bisect is a bit weird now btw, since it seems to be a bit confused by 5.3-5.4 merge that happened not when it thinks it did - so if you try to bisect changes in 5.4 branch only, you will get some very old changes in. You can quickly go through that, marking them as good, but still not ideal situation. Okay, since I'm not too familiar with release process, assume following (please, correct me if I'm wrong): * PHP 5.3 can't have features, only bugfixes True. * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and master) and bugfixes that should stay only in PHP-5.3 Not entirely true - 5.3 code can have bugfixes that aren't merged up, but that would not be the common case. Example - bugfix regarding magic quotes or safe mode, which are not in 5.4. * PHP-5.4 and master can have bugfixes and features that are merged upstream (master) and bugfixes/features that should stay only in current branch 5.4-only fixes very unlikely, as master and 5.4 are very close today. If we ever do big changes in master this is a possibility, as described above, but still won't be a common case - unless we rewrite our engine completely, which doesn't seem to be likely. * All branches are have regular releases True, except for master. In gitflow you have 4 branches: * master - contains only production ready releases, nobody commits here directly * develop - main development branch, all work usually is get merged here * feature/name - feature/bugfix branches for separate bugfixes and features. Merged into develop. * hotfix/name - same that feature branches but is urgent and is always merged into master *and* develop. For example, when security release is issued, this fix should go into release and into main development branch. * release/name - pre-release stability branches, for bug-fixes only. Merged into develop and master (making a new release). When you have a release branch, you can't commit into develop (so hotfixes go here too, if we have release branch). I don't like that can't commit into thing - the main advantage of git as I see it that you can manage release branch and dev/stable branches separately and not have the situation of asking people to sit on their code for 2 months while release is being stabilized. Make a bugfix in 5.3 $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 $ git flow feature finish -k bugfix 5.3-develop Bugfix get merged into 5.3-develop - this should be implemented since gitflow supports only 1 develop branch for now. -k says to keep branch after finish, since we'll need it to merge upstream Why would we need bugfix branch in our repo here? I would say keep it in your own fork, test it, show it off, get it ready - then merge it into php repo. What is the reason for us to keep halfbaked fix branches in our repo? Merge bugfix from 5.3 repo to 5.4 First, rebase branch against 5.4 $ git rebase --onto develop-5.4 bugfix~num bugfix Where num is number of commits in your branch. I know it sucks, but that's how it works :) I don't like it. Too fragile and too easy to mess up. In general, this scheme seems quite complex and I don't really see what the benefit of it would be. Could you explain why would we want to do this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
