I've add a section in "how to contribute" to describe how to commit patch in both master and release branch.
https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute#HowtoContribute-ForCommitters:howtocommitapatchinbothmasterandreleasebranch Feel free to update/correct it directly. :) Thanks, Evans 2015-07-18 13:21 GMT+08:00 Evans Ye <[email protected]>: > 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 >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >> >
