now we are kind of set back by this unfortunate result of Leo's work. new proposal:
We start using git-flow for 4.5/5.0 exclusively. as of then we will use the workflows as describe by him [1] 4.4.x will still be released by manual RM-cherry-picking (yes volunteer dragging his feet) Leo, are you prepared to write up a how-to cwiki page? kind regards, [1] http://markmail.org/message/on2l5n6uaucpuuwf On Thu, Jul 24, 2014 at 11:22 AM, Leo Simons <lsim...@schubergphilis.com> wrote: > On Jul 24, 2014, at 10:45 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: >> Any advice on our procedure from this, Leo? > > Yes, to follow all the git-flow defaults [1]. > > * goal is for master to become stable > * new develop which starts from master > * create with `git flow init` > * ‘abandon’ 4.4 / 4.4-forward > * anything in there which is not currently > in master gets cherry-picked into develop > * accordingly, plan is no 4.4.1 > * if 4.4.1 becomes really necessary, create > it by cherry-picking from develop > * keep 4.3 to produce 4.3.1 then > abandon it, too > > It is important to realize that a git-flow release/4.5 is _not_ the same as > an old-style 4.5-forward; a lot more discipline is required. > > 4.4-forward contains a lot of things which are not purely bugfixes. > 4.4-forward has additional tests, lots of changes to test suites, things that > should go in 4.4.1 but not 4.4.0, half-merged features that were pulled from > 4.4 but remain in 4.4-forward, bugfixes that include refactoring, etc etc. In > a git-flow model, those things would go onto feature/ and/or support/ > branches, and from there to the develop branch, and definitiely _never_ onto > a release branch. It was very hard to get 4.4 stable by cherry-picking from > 4.4-forward; the discipline suggested by git-flow is _exactly_ to avoid that > difficulty. > > Note git-flow defaults also include: > * feature branches are called feature/feature-thing > (don’t put your name in there, its meant to be > descriptive!) > * release branches are called release/{version} > (not RELEASE-{version}) > * hotfixes are called hotfix/{version}-name > and are based on & merge to master (not usually > to a release branch, release branches are not > hot, hotfixes are patches to previous releases, > i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes) > * everyone can commit on release branches, > everyone can merge to develop (generally you > don’t need much merging to release branches > since the only thing you commit there are > bugfixes, you merge _from_ the release branch > _to_ the develop branch), merging is _not_ a > release manager's job (the release manager might > review or approve bugfixes, but its the committer > that merges) > * no cherry-picking! > > > cheers, > > > Leo > > [1] unfortunately, the reason I did this analysis work yesterday was to try > and find a way to start from 4.4 and go forward from there, first merging in > 4.4-forward and then master, but I don’t see that happening > >> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <lsim...@schubergphilis.com> >> wrote: >>> branch two diff size big diff chunks >>> branch one >>> 4.3 4.4 11MB hyperv,netscaler,server,engine >>> 4.4 4.4-forward 2MB tests,marvin >>> 4.4-forward master 6MB xenapi,xen,xenserver,storage >>> 4.4 master 8MB xenapi,tests,marvin,xen,xenserver >>> (See below how I got the numbers.) >>> >>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from >>> master means processing hundreds of thousands of lines of diff. Of those >>> lines, many many thousands of lines will probably not auto-merge due to the >>> cherry-pick approach. A rebase between any of these branches is not >>> feasible; git cannot un-pick what happened so it cannot offer much >>> assistance. > -- Daan
