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? > >> > > >
