I don't really like how 3.2.2 is feeling. We've had a number of bugs, documentation holes, etc. I think we should hold off on opening the tp32 branch a bit longer and focus on firming up these problems before anyone worries about 3.3.x too much. Unless anyone feels differently, I'll not look to setup tp32 this coming weekend. We can revisit moving forward on the tp32 branch for next week.
On Tue, Sep 13, 2016 at 8:43 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > While we haven't started the tp32 branch yet, I thought I'd do the dual PR > model for a bug fix that i had on tp31 just to see how it would go. So I > created two branches using the git commands i specified in my last post on > this thread: > > TINKERPOP-1442 > TINKERPOP-1442-master > > and created two PRs from them: > > https://github.com/apache/tinkerpop/pull/412 > https://github.com/apache/tinkerpop/pull/413 > > I think it was helpful to "tag" the target branch in the PR description so > it was easy to figure out just from the PR list which one you were looking > at. In this case, this was a pretty easy merge situation as there wasn't > much divergence between the branches. A nice part about this approach is > that it forces specific testing of the integration of the code to each > branch, so even though the code changes are pretty much identical, we are > assured that some other difference elsewhere between the branches doesn't > create some havoc we didn't know about. > > I suppose the VOTE should still occur on both PRs prior to merging. I > think it will be confusing any other way. > > We will need to take care when merging CTR'd work to not inadvertently > merge commits destined for master on a PR that is under review. I sense > that is possible with this model. If you CTR to tp32 and attempt a merge to > master and get "more" commits than just your CTR, you should take a closer > look at what it is going on. I think this also means that we need to not > merge the tp32 PR without also being ready to merge the master PR. They > should both happen in fairly fast succession of one another. > > sorry - boring post - thanks for reading. > > On Tue, Sep 13, 2016 at 8:08 AM, Stephen Mallette <spmalle...@gmail.com> > wrote: > >> As there have been no objections, we will go with the PR per branch model >> when we open the tp32 branch this coming weekend. The flow is pretty >> simple. Let's say you have work for tp32: >> >> 1. git checkout -b <TINKERPOP-1234> tp32 >> 2. do a bunch of stuff and commit in there >> 3. git checkout -b <TINKERPOP1234-master> master >> 4. git merge TINKERPOP-1234 >> >> That produces two branches, one for tp32 and one for master, from which >> you can formulate the PRs in GitHub. One issue I thought of this morning >> was what to do in the case of CTRs where we commit directly to tp32. In >> those cases, the committer should immediately merge to master as we >> normally do: >> >> git checkout master >> git merge tp32 >> >> Presumably, CTR'd work will be a single small commit that is easy to >> merge. I think we should try to avoid cherry-pick in this model as it >> re-writes history (i.e. new hash generated for the cherry-picked commit). >> If we need a commit to stay in tp31 there are ways to do the merge without >> bringing that specific commit forward. Hope that all makes sense to >> everyone. I'll probably add something to the dev docs about this model for >> when we get stated with tp32 next week. >> >> >> On Thu, Sep 8, 2016 at 3:47 PM, Daniel Kuppitz <m...@gremlin.guru> wrote: >> >>> Sounds good to me. It won't necessarily mean much more work, since I >>> assume >>> that most branches won't have any merge conflicts. >>> >>> Cheers, >>> Daniel >>> >>> >>> On Thu, Sep 8, 2016 at 6:36 PM, Stephen Mallette <spmalle...@gmail.com> >>> wrote: >>> >>> > I think 3.3.0 will be a "big" release with many breaking changes as we >>> > remove deprecation, upgrade certain dependencies, and make other >>> usability >>> > improvements. This won't be a release we want to rush as it affords us >>> an >>> > opportunity to make a number of things a lot better. I believe that >>> we'd >>> > discussed having 3.3.0 as a release for the end of 2016, but the more I >>> > think about it, the more I wonder if that's enough time. >>> > >>> > Anyway, I think that if we hope to get a 3.3.0 out by end of 2016 or >>> early >>> > 2017, we will need to get started sooner than later. That of course, >>> would >>> > lead us to our branching model in git and how we will want to approach >>> > that. >>> > >>> > Right now, things are pretty simple. We maintain master and tp31 >>> branches >>> > and tp31 merges one-way to master. If we want to start work on 3.3.0, >>> then >>> > I think we should begin a tp32 branch for the 3.2.x line of code and >>> make >>> > master be 3.3.x. Of course, that complicates our workflow slightly >>> because >>> > tp31 will need to merge to tp32 and then tp32 to master. While tp31 >>> > development has ceased with the exception of bug fixes, I already find >>> > divergence between tp31 and master as things stand today and that will >>> only >>> > get worse as we make breaking change to master. The point is that it >>> may be >>> > burdensome to merge tp32 to master at times for those other than the >>> > original author of the work being merged. >>> > >>> > We may find that we may need a multi-pull request model to cleanly deal >>> > with conflicts inherent to the merge. In other words, a change to tp31 >>> > would mean a separate pull request to tp31, tp32 and master (as >>> opposed to >>> > one pull request to tp31 with a merge at some later time to tp32 and >>> then >>> > at some later time tp32 to master). For a change to tp32 you would >>> just do >>> > a PR to tp32 and a PR to master. That would be the safest way to deal >>> with >>> > conflicts and not have any surprises for some poor sap doing a blind >>> merge >>> > from one of our release branches down the line. >>> > >>> > Any thoughts on any of this? >>> > >>> >> >> >
