Re: Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 01:42:16 David Jarvie wrote: On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: There is no active policy saying you're supposed to merge. Almost everybody in KDE is still doing cherry-picks. KDevelop is the only KDE project I know that consistently uses forward-merges from the stable branch to master. --- It *would* be good to switch to the new workflow of doing changes in the lowest supported branch and up-merging, but it's not that easy. We need to: - Figure out how to solve the scripty problem. scripty does its own conflicting commits to .desktop files in both branches, and that won't change[1]. We probably need a custom merge tool for .desktop-like files that ignores translations. - Check if there is any change in 4.7 that isn't in master, and if so, see if that's intentional (4.7-specific hack, or the version bumps) or an oversight (never cherry-picked into master). - Do the initial merge from 4.7 to master, solving the conflicts. The more they have diverged, the harder this is. - Get *everyone* to start with the new workflow for that particular repository (see below). Else, if some people keep cherry-picking while others expect merging, the next one to try merging may get conflicts about all the cherry-picks people did since the last merge, and a merge will make commits appear duplicated in the log (as ossi pointed out to me). During the stable branch freeze before a minor version release (such as currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes. Seriously: is this technically enforced or is it believed that developers know about it? Personally I have no idea when the stable branch will be tagged or released. I commit to the stable branch in order to fix a bug and in the hope that it will some day end on the users' systems. But I do not care when this will happen and I never was blocked because of some tagging freeze. So unless this is not technically enforced, the policy are nice words which I beleive nobody cares about. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Re: Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 19:28:53 Ben Cooksley wrote: During the stable branch freeze before a minor version release (such as currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes. Seriously: is this technically enforced or is it believed that developers know about it? Technically enforced: No All developers should know about it, as they were sent a set of instructions from sysadmin when they gained access to KDE SCM servers. A copy of it can be found at http://websvn.kde.org/trunk/kde-common/svn/svn_git_instructions.txt?view=markup It contains a link to http://techbase.kde.org/Policies/SVN_Commit_Policy (which also applies to git i'll add) That has a section Respect commit policies set by the Release Plans. Please understand that what I pointed out is in no way any disrespect for the release team. I just want to point out that such community rules can easily be missed if not technically enforced and that such freezes are very fuzzy and maybe unknown. In comparison for feature freezes all KDE developers are notified through the cvs mailinglist. Personally I have no idea when the stable branch will be tagged or released. I commit to the stable branch in order to fix a bug and in the hope that it will some day end on the users' systems. But I do not care when this will happen and I never was blocked because of some tagging freeze. We have Release Plans published on the wiki, and available as an ics file on www.kde.org which matches that for use in Kontact, etc. The release plan states for final tagging: The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. Given that all deadlines are due 23:59 UTC I understand that I can commit all the day and that the tagging appears directly at 00:00 UTC which will immediatelly unfreeze the branch for fixes to 4.7.1. That is exaggerated, but points out a problem: there is no unfreeze date specified. Given that Dirk does not tag immediatelly, it is for a developer completely imprecticale to know when it is allowed again to commit. Without technical enforcement such freezes just cannot work. For minor releases there is no freeze at all: A KDE minor release is tagged and made available to the packagers. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Fixes in Git (first in stable, then merge to master)
Nicolas Alvarez wrote: - Figure out how to solve the scripty problem. scripty does its own conflicting commits to .desktop files in both branches, and that won't change[1]. We probably need a custom merge tool for .desktop-like files that ignores translations. I *think* I managed to write such a merge tool. I still need more testing and fixing. For example, if there is an actual file conflict, I'm handling it pretty badly right now (no conflict markers or anything). Also, when merging 4.7 into master, it seems that if a .desktop file was only modified in 4.7, git will do the merge automatically, bringing those 4.7 changes into master, without running the custom merge tool. Those changes would be undone again next time scripty runs. But this seems promising anyway. Stay tuned :) -- Nicolas
Re: Fixes in Git (first in stable, then merge to master)
Am 7/21/2011 23:22, schrieb Aurélien Gâteau: What I have been doing recently to avoid cherry-picking is to create my fixes in a separate work branch, then merge the branch in both 4.7 and master branches. This way the commits do not have different commit ids. But this works only if you fork off your topic from a commit that is in both 4.7 and master, i.e., before 4.7 and master forked. Do you do that? This is a very reasonable (and git-ish) way to avoid cherry-picks and still avoid merging 4.7 into master. (But the latter, avoiding to merge 4.7 into master, is very un-git-ish.) -- Hannes
Re: Fixes in Git (first in stable, then merge to master)
Alex Fiestas wrote: Last few days I have been patching some pieces of our workspace here and there, the first set of patches I did them directly into master which if I remember correctly was against the policy. So, the second round of fixes I tried to do it the right way, which is: 1-Create the patch while using 4.7 (optional I guess) 2-Test the patch in 4.7 3-Commit the patch in 4.7 4-Checkout master branch 5-Merge 4.7 into master [...] So, at this point I'm wondering if the policy is bad or (and this option is the more plausible) I don't know how to use the tool. Cheers and sorry for the cherry-pick's I've done so far. There is no active policy saying you're supposed to merge. Almost everybody in KDE is still doing cherry-picks. KDevelop is the only KDE project I know that consistently uses forward-merges from the stable branch to master. --- It *would* be good to switch to the new workflow of doing changes in the lowest supported branch and up-merging, but it's not that easy. We need to: - Figure out how to solve the scripty problem. scripty does its own conflicting commits to .desktop files in both branches, and that won't change[1]. We probably need a custom merge tool for .desktop-like files that ignores translations. - Check if there is any change in 4.7 that isn't in master, and if so, see if that's intentional (4.7-specific hack, or the version bumps) or an oversight (never cherry-picked into master). - Do the initial merge from 4.7 to master, solving the conflicts. The more they have diverged, the harder this is. - Get *everyone* to start with the new workflow for that particular repository (see below). Else, if some people keep cherry-picking while others expect merging, the next one to try merging may get conflicts about all the cherry-picks people did since the last merge, and a merge will make commits appear duplicated in the log (as ossi pointed out to me). Off to read about custom git merge drivers... -- Nicolas
Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: There is no active policy saying you're supposed to merge. Almost everybody in KDE is still doing cherry-picks. KDevelop is the only KDE project I know that consistently uses forward-merges from the stable branch to master. --- It *would* be good to switch to the new workflow of doing changes in the lowest supported branch and up-merging, but it's not that easy. We need to: - Figure out how to solve the scripty problem. scripty does its own conflicting commits to .desktop files in both branches, and that won't change[1]. We probably need a custom merge tool for .desktop-like files that ignores translations. - Check if there is any change in 4.7 that isn't in master, and if so, see if that's intentional (4.7-specific hack, or the version bumps) or an oversight (never cherry-picked into master). - Do the initial merge from 4.7 to master, solving the conflicts. The more they have diverged, the harder this is. - Get *everyone* to start with the new workflow for that particular repository (see below). Else, if some people keep cherry-picking while others expect merging, the next one to try merging may get conflicts about all the cherry-picks people did since the last merge, and a merge will make commits appear duplicated in the log (as ossi pointed out to me). During the stable branch freeze before a minor version release (such as currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Fixes in Git (first in stable, then merge to master)
Le 20/07/2011 11:52, Alex Fiestas a écrit : Hi there Last few days I have been patching some pieces of our workspace here and there, the first set of patches I did them directly into master which if I remember correctly was against the policy. So, the second round of fixes I tried to do it the right way, which is: 1-Create the patch while using 4.7 (optional I guess) 2-Test the patch in 4.7 3-Commit the patch in 4.7 4-Checkout master branch 5-Merge 4.7 into master In theory, this workflow should work (I like it dcvs-wise) but the reality for me was: 1-A lot of conlicts 2-Conlicts on software I don't know about 3-Conflicts in .desktop translations 4-Something that should be almost instant, is not at all The result of a merge of 4.7 in master can be observed in the attached screenshot. So, at this point I'm wondering if the policy is bad or (and this option is the more plausible) I don't know how to use the tool. What I have been doing recently to avoid cherry-picking is to create my fixes in a separate work branch, then merge the branch in both 4.7 and master branches. This way the commits do not have different commit ids. Aurélien
Re: Fixes in Git (first in stable, then merge to master)
On Wed, Jul 20, 2011 at 11:52:31AM +0200, Alex Fiestas wrote: 5-Merge 4.7 into master have you slept the last months? ;) kde continues to use a cherry-pick policy. *don't* forward-merge.
Re: Fixes in Git (first in stable, then merge to master)
On Wednesday 20 July 2011 11:52:31 Alex Fiestas wrote: Hi there Last few days I have been patching some pieces of our workspace here and there, the first set of patches I did them directly into master which if I remember correctly was against the policy. So, the second round of fixes I tried to do it the right way, which is: 1-Create the patch while using 4.7 (optional I guess) 2-Test the patch in 4.7 3-Commit the patch in 4.7 4-Checkout master branch 5-Merge 4.7 into master I tried forward-merging till scripty started to process master again. When I received such merge conflicts as in the screen shot, I gave up, because I just did not know how to do that merge in a correct way and hoped that someone more git skilled would fix it. Seems like it did not happen so far :-( Cheers Martin signature.asc Description: This is a digitally signed message part.
