Kicking off this discussion with my own opinions inline:
On Tue, Jul 31, 2018 at 5:04 PM Renan DelValle <re...@apache.org> wrote: > All, > > I wanted to take a few minutes to explain what our recent change to gitbox > means in practice. > > For our users: > * The change is (hopefully) not very impactful. The only thing that > changes is the location of the aurora and aurora-packing repositories. > Update those as needed by your usage. > * You may now depend on the github repository as the main source of aurora > code. > > For our developers (and, more importantly, future developers): > * You can now make contributions by making Pull Requests through the > github.com UI! > * Contributors may still submit contributions through the Review Board > workflow. > > For our committers: > * You can now commit Pull Requests directly through the github UI. > * You may also continue to commit contributions through the Review Board > workflow. > * Origin is now g...@github.com:apache/aurora.git All pushes committing > new code from contributions should be made there. > * aurora-packaging has a protected master branch. This means commits > cannot be directly pushed to master -- only through pull requests. This is > to avoid accidental pushes to the master. Review Board flow is still > possible here but an extra step is required. > > Finally a few points of discussion: > > * Should we enable issues on github for both aurora and aurora-packaging? > If yes, should this replace JIRA for aurora and aurora-packaging? (A vote > is probably in order for this if the overall sentiment is positive) > I'm +1 for enabling github issues on both aurora and aurora-packaging. With a strong +1 for enabling them on aurora-packaging. I would like github issues to take over for JIRA as I feel JIRA is too heavy weight for our current level of activity. > > * Should we eventually make the master branch on aurora be protected? If > yes, when should the cutover be? > For me this is something that should eventually be done. I can't recall any push by accident moments that have taken place but better safe than sorry. In either case, I don't feel too strongly about this. > > * Should we favor PRs as the main way of making contributions? When (if at > all) should Review Board be favored over PRs? > For all new contributors, I am of the opinion that PRs are the easiest way for new contributors to make an impact. Therefore, I feel we should favor PRs for new contributors and old contributors may feel free to choose for themselves. > > * For pull requests, what should our PR merge model be? > The choices are: > - Merge commit > - Squash and merge > - Rebase and merge > > Note: Squash and merge is the closest to our current Review Board workflow. > Our squash and merge like merge has served us well in the past. I vote to use this merge method on PRs as well for consistency with Review Board contributions. > > * We need a CI for contributions made through github. Suggestions, > recommendations, as well as help setting them up are very much welcome. > No opinions here but Travis CI looks like the path of least resistance. > > -Renan >
