Regarding our recent move to gitbox

[Renan DelValle <re...@apache.org>]

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 git@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)

* Should we eventually make the master branch on aurora be protected? If
yes, when should the cutover be?

* Should we favor PRs as the main way of making contributions? When (if at
all) should Review Board be favored over PRs?

* 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.

* We need a CI for contributions made through github. Suggestions,
recommendations, as well as help setting them up are very much welcome.

-Renan

Re: Regarding our recent move to gitbox

[Jing Chen <mi...@gmail.com>]

I'm +1 for enabling github issues on aurora-packaging

I am cool with enabling github issues on aurora, however, it is not easy to
maintain if too many issues are created.
It might be a good option for our current level of activity though.

On Wed, Aug 1, 2018 at 11:48 AM Renan DelValle <re...@apache.org> wrote:

> 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 git@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
> >
>

Re: Regarding our recent move to gitbox

[Renan DelValle <re...@apache.org>]

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 git@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
>