Good questions... > 1. we would be pushing the original commits and each merge as PRs?
Here's what I just did moments ago. We started with this: https://github.com/apache/tinkerpop/pull/952 [tp32 branch] That originally came from a third-party. We reviewed and voted that. When it was "ok" (i.e. three +1s in this case) I opted to create PRs for the other branches: https://github.com/apache/tinkerpop/pull/956 [tp33] https://github.com/apache/tinkerpop/pull/957 [master] why? because: 1. i can see exactly what's going into the release branches through github 2. i get travis builds and they will merge as-viewed/as-tested with the "Merge Pull Request" button 3. because i use the "Merge Pull Request" button there's no weird secondary merge commits and even less chance for having git in a weird state for another committer when they pull Do we always have to follow this pattern for every PR? I think we can leave that to the discretion of the committer. Sometimes for a small change it may not be worth the energy and you can just command line all of it. In other cases, where there are conflicts and such, it might be better to follow this approach. Btw, Travis has been much more stable in recent months (my opinion) as I've been slowly tweaking tests that have been non-deterministic in the past and it's finally getting to a point where a failure might actually mean something AND now that we can force rebuild directly with a button push....that's even more incentive to go this route. > 2. do we have to VOTE on each branch PR for the same issue? I'd say "no", unless the committer wants extra review - e.g. something that was heavily conflicted. > 2a. what if they have different vote results? does one block the other? i suppose that could happen but it's never happened yet. it would be like there was a change in tp32 that we didn't want in tp33. since that has never happened i don't know what we'd do but discuss it and come to some consensus on how to proceed. i think that's what we'd do now if that every occurred. On Mon, Oct 8, 2018 at 3:38 PM Robert Dale <[email protected]> wrote: > So, > 1. we would be pushing the original commits and each merge as PRs? > 2. do we have to VOTE on each branch PR for the same issue? > 2a. what if they have different vote results? does one block the other? > > Robert Dale > > > On Mon, Oct 8, 2018 at 11:52 AM Stephen Mallette <[email protected]> > wrote: > > > I made a handful of fixes to dev docs - reflects some of the things I > wrote > > on this thread: > > > > > > > https://github.com/apache/tinkerpop/commit/3ec14cbad6abc0483bae91775956ce6af812627a > > > > we can tweak further as necessary - thanks > > > > > > On Mon, Oct 8, 2018 at 9:04 AM Stephen Mallette <[email protected]> > > wrote: > > > > > wow - the "Restart Build" button in Travis works now and of course the > > > "Close Pull Request" button is enabled. no more "git commit > > > --allow-empty"............. > > > > > > On Mon, Oct 8, 2018 at 8:19 AM Stephen Mallette <[email protected]> > > > wrote: > > > > > >> Just used the "Merge Pull Request" button now that we have GitBox and > > >> that felt good. > > >> > > >> Now that we have push access to github, I believe we want some changes > > to > > >> our git flow. Here's some thoughts: > > >> > > >> 1. Avoid manual merges for most things and prefer the "Merge PR" > button > > >> in GitHub > > >> 2. Issue PRs to each branch that will be updated > > >> 3. Use the "Merge PR" button in reverse version order (as we should be > > >> doing now with manual merges - merge master first, then tp33 and then > > tp32) > > >> 4. I suppose that for external PRs we could ask the submitter to issue > > >> multiple PRs depending on the base branch they are targeting, but that > > >> might create some extra friction for new contributors. Maybe we > > committers > > >> should just create those PRs for them in those cases (unless they are > > >> conflicted badly then perhaps the submitter should go back and deal > with > > >> that). > > >> 5. CTRs will still need manual merging so I guess that doesn't go > away. > > >> > > >> Any other ideas? > > >> > > > > > >
