OK, then we better have this updated on Committer's wiki. Olaf's workflow.sh is a good demonstration, just need to indicate which the source branch is.
I just discovered that my cwiki account got locked so I'm currently approaching apache infra. Will update if no one before me. :) 2015-07-16 6:14 GMT+08:00 Konstantin Boudnik <[email protected]>: > Yup, I believe this is wht I am saying. The fix-branch (in this particular > case, as new features shouldn't be added to old releases, IMO) should be > derived from the "least common denominator" branch to make both merges as > seamless as possible. > > Cos > > On Thu, Jul 16, 2015 at 02:29AM, Evans Ye wrote: > > Since I'm one of the "author" of the current 1.0 branch, I'd like to join > > the discussion and make sure whether I get it right. > > > > It looks like the the proposed approach is to replace cherry-pick by > > creating a feature branch and merge that branch into branches we'd like > to > > have the fix. > > > > If we're going this approach, then the feature branch should be derived > > from the targeted back port branch. For example, if patch A is getting in > > both branch-1.0 and master, then we should create a feature branch from > 1.0 > > name branch-A, and add patch A on top of branch-A, and then merge > branch-A > > into branch-1.0 and master, respectively. > > > > Basically, the above is what I concluded from your discussion. Is this > the > > same as what you're thinking? > > > > > > 2015-07-15 22:34 GMT+08:00 Olaf Flebbe <[email protected]>: > > > > > Cos, > > > > > > > Evidently, "is not mutable" and "shouldn't be moved" are two very > > > different > > > > properties. > > > > > > Of course, you are right. > > > > > > > What github does for their releases is of no relevance to us,. > > > > > > You are right, but I would like to mention we use this in bigtop.mk, > too. > > > > > > HUE_SITE=https://github.com/cloudera/hue/archive > > > DATAFU_SITE=https://github.com/linkedin/datafu/archive > > > TACHYON_SITE=https://github.com/amplab/tachyon/archive > > > > > > I would pledge for putting an tag release-1.0.0 on the release commit > . > > > Like we did before. > > > > > > >> I doubt you can move a tag once it is pushed to the apache > repository > > > (since > > > >> a force push is not possible, too), but we may try ;-) > > > > > > > > Tag is a pointer to a git object. The pointer could be deleted, > > > recreated and > > > > pushed again: no force-push is needed for that. > > > > > > That is evidently not true: > > > > > > $ git tag -d olaf > > > Deleted tag 'olaf' (was 6fd647e) > > > $ git tag olaf HEAD~3 > > > $ git push lr --tags > > > ... > > > ! [rejected] olaf -> olaf (already exists) > > > error: failed to push some refs to '.....' > > > > > > > > > > Besides, force-push isn't disabled on Apache repos (except for master > > > branch). > > > > > > > Yes, we can do whatever we want with the branches. > > > > > > > > > Didn't know that. Now I am beginning to understand your point ... > > > > > > I wrote an example workflow (see attachement) . I would propose to add > > > this example (if it is correct) to the developer guidelines in the > wiki. > > > > > > Management summary: We should be careful not to apply changes affecting > > > both release and master directly to one of these branches. Use a fix > branch > > > instead and merge it to both master and release branch. > > > > > > Using github pull request seems equivalent to this workflow, btw. > > > > > > Thanks all for your patience, over and out. > > > Olaf > > > > > > > > > > > > > > > > > > > > > > > > > >
