You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Ismael Juma <is...@juma.me.uk> on 2017/12/10 07:35:47 UTC
[DISCUSS] Allowing write access to GitHub repositories
Hi all,
The Apache Infra team has started a new project earlier this year called
GitBox that supports two-way synchronization between GitHub and
git-wip-us.apache.org and, most importantly, provides GitHub write access
to committers. GitBox is not generally available yet, but individual
projects can ask to be migrated.
I think we should migrate kafka and kafka-site to GitBox. The main benefit
is that pull request management will be hugely improved for committers:
1. Reviewers functionality will become available
2. Pull requests will be assignable to GitHub users
3. We will be able to assign labels to issues
4. We will be able to merge pull requests directly via GitHub instead of
using the merge script
5. Committers will be able to close old and stale PRs
6. We will be able to use protected branches to restrict merges via GitHub
to only be allowed if tests pass and the PR has been approved by at least
one committer
A couple of potential downsides:
1. To avoid weird behaviour (even though two way synchronization exists),
we'd want all committers to always push to GitHub, but this won't be
enforced. That is, git-wip-us.apache.org will still be writable. Given the
small number of active committers, this seems to be a minor issue.
2. If we decide to drop the merge script in favour of GitHub, some of the
functionality will have to be done manually. GitHub supports "squash and
merge" via the UI, so the main things that will have to be done manually
are (1) Ensuring that the commit message follows the right format (2) Close
the JIRA ticket. I think this is OK, but we could allow both options (merge
and GitHub UI). If we want to allow both options, we'd just change the
default push repository in the script to be GitHub.
All in all, I think this is a clear improvement and fixes a lot of the pull
request management pain points we've been facing. Given that, I'd like to
move quickly, if possible.
Please share your thoughts below and if people are in favour, I'll start a
vote.
Ismael
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Ismael Juma <is...@juma.me.uk>.
Thanks. Since this seems like a clear win I'll start the vote thread. Any
other thoughts are welcome, of course.
Ismael
On Tue, Dec 12, 2017 at 12:40 PM, Damian Guy <da...@gmail.com> wrote:
> +1
>
> On Tue, 12 Dec 2017 at 10:20 Rajini Sivaram <ra...@gmail.com>
> wrote:
>
> > Hi Ismael,
> >
> > Thank you for looking into this. Sounds like a good improvement.
> >
> > Regards,
> >
> > Rajini
> >
> > On Mon, Dec 11, 2017 at 6:35 AM, Guozhang Wang <wa...@gmail.com>
> wrote:
> >
> > > Sounds good to me.
> > >
> > > On Sun, Dec 10, 2017 at 10:14 PM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > >
> > > > Thanks Guozhang.
> > > >
> > > > Cherry-picking also occurred to me sometime after I sent the email
> and
> > I
> > > > agree that it's useful functionality.
> > > >
> > > > Do I understand correctly that you are suggesting a script for
> > > > cherry-picking after the pull request has been merged? We could
> explore
> > > > this, but not sure it would add much over plain `git cherry-pick` for
> > > > typical AK usage. Given that, I am tempted to just allow both the
> > current
> > > > merge script and the GitHub UI to be used. And after a period of a
> few
> > > > weeks/months, we can look at improvements based on actual experience.
> > How
> > > > does that sound?
> > > >
> > > > Ismael
> > > >
> > > > On Mon, Dec 11, 2017 at 7:15 AM, Guozhang Wang <wa...@gmail.com>
> > > wrote:
> > > >
> > > > > Thanks Ismael for initiating this discussion. I am in favor for
> > > adopting
> > > > > Gitbox for its clean improvements since many of us have shared the
> > pain
> > > > of
> > > > > managing PRs for long time.
> > > > >
> > > > > About this potential downsides, subjectively I feel these two
> > arguments
> > > > are
> > > > > quite handle-able. The only concern I had about cherry-picking to
> > other
> > > > > branches, which is a very common usage of the script tool we used
> > > today.
> > > > So
> > > > > I'd suggest simplifying that script to help with cherry-picking
> > > > (currently
> > > > > we only do up-stream cherry-picking, but we could also consider
> allow
> > > > both
> > > > > upstream and downstream cherry-picking) than completely discard it.
> > > > >
> > > > >
> > > > > Guozhang
> > > > >
> > > > > On Sat, Dec 9, 2017 at 11:39 PM, Ismael Juma <is...@juma.me.uk>
> > > wrote:
> > > > >
> > > > > > One thing I forgot to mention, many projects have requested and
> > been
> > > > > using
> > > > > > GitBox for a while:
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/INFRA-15271?jql=
> > > > > > project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%
> > > > > > 20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%
> > > > > > 20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> > > > > >
> > > > > > On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk>
> > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > The Apache Infra team has started a new project earlier this
> year
> > > > > called
> > > > > > > GitBox that supports two-way synchronization between GitHub and
> > > > > > > git-wip-us.apache.org and, most importantly, provides GitHub
> > write
> > > > > > access
> > > > > > > to committers. GitBox is not generally available yet, but
> > > individual
> > > > > > > projects can ask to be migrated.
> > > > > > >
> > > > > > > I think we should migrate kafka and kafka-site to GitBox. The
> > main
> > > > > > benefit
> > > > > > > is that pull request management will be hugely improved for
> > > > committers:
> > > > > > >
> > > > > > > 1. Reviewers functionality will become available
> > > > > > >
> > > > > > > 2. Pull requests will be assignable to GitHub users
> > > > > > >
> > > > > > > 3. We will be able to assign labels to issues
> > > > > > >
> > > > > > > 4. We will be able to merge pull requests directly via GitHub
> > > instead
> > > > > of
> > > > > > > using the merge script
> > > > > > >
> > > > > > > 5. Committers will be able to close old and stale PRs
> > > > > > >
> > > > > > > 6. We will be able to use protected branches to restrict merges
> > via
> > > > > > GitHub
> > > > > > > to only be allowed if tests pass and the PR has been approved
> by
> > at
> > > > > least
> > > > > > > one committer
> > > > > > >
> > > > > > > A couple of potential downsides:
> > > > > > >
> > > > > > > 1. To avoid weird behaviour (even though two way
> synchronization
> > > > > exists),
> > > > > > > we'd want all committers to always push to GitHub, but this
> won't
> > > be
> > > > > > > enforced. That is, git-wip-us.apache.org will still be
> writable.
> > > > Given
> > > > > > > the small number of active committers, this seems to be a minor
> > > > issue.
> > > > > > >
> > > > > > > 2. If we decide to drop the merge script in favour of GitHub,
> > some
> > > of
> > > > > the
> > > > > > > functionality will have to be done manually. GitHub supports
> > > "squash
> > > > > and
> > > > > > > merge" via the UI, so the main things that will have to be done
> > > > > manually
> > > > > > > are (1) Ensuring that the commit message follows the right
> format
> > > (2)
> > > > > > Close
> > > > > > > the JIRA ticket. I think this is OK, but we could allow both
> > > options
> > > > > > (merge
> > > > > > > and GitHub UI). If we want to allow both options, we'd just
> > change
> > > > the
> > > > > > > default push repository in the script to be GitHub.
> > > > > > >
> > > > > > > All in all, I think this is a clear improvement and fixes a lot
> > of
> > > > the
> > > > > > > pull request management pain points we've been facing. Given
> > that,
> > > > I'd
> > > > > > like
> > > > > > > to move quickly, if possible.
> > > > > > >
> > > > > > > Please share your thoughts below and if people are in favour,
> > I'll
> > > > > start
> > > > > > a
> > > > > > > vote.
> > > > > > >
> > > > > > > Ismael
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Damian Guy <da...@gmail.com>.
+1
On Tue, 12 Dec 2017 at 10:20 Rajini Sivaram <ra...@gmail.com> wrote:
> Hi Ismael,
>
> Thank you for looking into this. Sounds like a good improvement.
>
> Regards,
>
> Rajini
>
> On Mon, Dec 11, 2017 at 6:35 AM, Guozhang Wang <wa...@gmail.com> wrote:
>
> > Sounds good to me.
> >
> > On Sun, Dec 10, 2017 at 10:14 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > Thanks Guozhang.
> > >
> > > Cherry-picking also occurred to me sometime after I sent the email and
> I
> > > agree that it's useful functionality.
> > >
> > > Do I understand correctly that you are suggesting a script for
> > > cherry-picking after the pull request has been merged? We could explore
> > > this, but not sure it would add much over plain `git cherry-pick` for
> > > typical AK usage. Given that, I am tempted to just allow both the
> current
> > > merge script and the GitHub UI to be used. And after a period of a few
> > > weeks/months, we can look at improvements based on actual experience.
> How
> > > does that sound?
> > >
> > > Ismael
> > >
> > > On Mon, Dec 11, 2017 at 7:15 AM, Guozhang Wang <wa...@gmail.com>
> > wrote:
> > >
> > > > Thanks Ismael for initiating this discussion. I am in favor for
> > adopting
> > > > Gitbox for its clean improvements since many of us have shared the
> pain
> > > of
> > > > managing PRs for long time.
> > > >
> > > > About this potential downsides, subjectively I feel these two
> arguments
> > > are
> > > > quite handle-able. The only concern I had about cherry-picking to
> other
> > > > branches, which is a very common usage of the script tool we used
> > today.
> > > So
> > > > I'd suggest simplifying that script to help with cherry-picking
> > > (currently
> > > > we only do up-stream cherry-picking, but we could also consider allow
> > > both
> > > > upstream and downstream cherry-picking) than completely discard it.
> > > >
> > > >
> > > > Guozhang
> > > >
> > > > On Sat, Dec 9, 2017 at 11:39 PM, Ismael Juma <is...@juma.me.uk>
> > wrote:
> > > >
> > > > > One thing I forgot to mention, many projects have requested and
> been
> > > > using
> > > > > GitBox for a while:
> > > > >
> > > > > https://issues.apache.org/jira/browse/INFRA-15271?jql=
> > > > > project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%
> > > > > 20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%
> > > > > 20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> > > > >
> > > > > On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk>
> > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > The Apache Infra team has started a new project earlier this year
> > > > called
> > > > > > GitBox that supports two-way synchronization between GitHub and
> > > > > > git-wip-us.apache.org and, most importantly, provides GitHub
> write
> > > > > access
> > > > > > to committers. GitBox is not generally available yet, but
> > individual
> > > > > > projects can ask to be migrated.
> > > > > >
> > > > > > I think we should migrate kafka and kafka-site to GitBox. The
> main
> > > > > benefit
> > > > > > is that pull request management will be hugely improved for
> > > committers:
> > > > > >
> > > > > > 1. Reviewers functionality will become available
> > > > > >
> > > > > > 2. Pull requests will be assignable to GitHub users
> > > > > >
> > > > > > 3. We will be able to assign labels to issues
> > > > > >
> > > > > > 4. We will be able to merge pull requests directly via GitHub
> > instead
> > > > of
> > > > > > using the merge script
> > > > > >
> > > > > > 5. Committers will be able to close old and stale PRs
> > > > > >
> > > > > > 6. We will be able to use protected branches to restrict merges
> via
> > > > > GitHub
> > > > > > to only be allowed if tests pass and the PR has been approved by
> at
> > > > least
> > > > > > one committer
> > > > > >
> > > > > > A couple of potential downsides:
> > > > > >
> > > > > > 1. To avoid weird behaviour (even though two way synchronization
> > > > exists),
> > > > > > we'd want all committers to always push to GitHub, but this won't
> > be
> > > > > > enforced. That is, git-wip-us.apache.org will still be writable.
> > > Given
> > > > > > the small number of active committers, this seems to be a minor
> > > issue.
> > > > > >
> > > > > > 2. If we decide to drop the merge script in favour of GitHub,
> some
> > of
> > > > the
> > > > > > functionality will have to be done manually. GitHub supports
> > "squash
> > > > and
> > > > > > merge" via the UI, so the main things that will have to be done
> > > > manually
> > > > > > are (1) Ensuring that the commit message follows the right format
> > (2)
> > > > > Close
> > > > > > the JIRA ticket. I think this is OK, but we could allow both
> > options
> > > > > (merge
> > > > > > and GitHub UI). If we want to allow both options, we'd just
> change
> > > the
> > > > > > default push repository in the script to be GitHub.
> > > > > >
> > > > > > All in all, I think this is a clear improvement and fixes a lot
> of
> > > the
> > > > > > pull request management pain points we've been facing. Given
> that,
> > > I'd
> > > > > like
> > > > > > to move quickly, if possible.
> > > > > >
> > > > > > Please share your thoughts below and if people are in favour,
> I'll
> > > > start
> > > > > a
> > > > > > vote.
> > > > > >
> > > > > > Ismael
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > -- Guozhang
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Rajini Sivaram <ra...@gmail.com>.
Hi Ismael,
Thank you for looking into this. Sounds like a good improvement.
Regards,
Rajini
On Mon, Dec 11, 2017 at 6:35 AM, Guozhang Wang <wa...@gmail.com> wrote:
> Sounds good to me.
>
> On Sun, Dec 10, 2017 at 10:14 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > Thanks Guozhang.
> >
> > Cherry-picking also occurred to me sometime after I sent the email and I
> > agree that it's useful functionality.
> >
> > Do I understand correctly that you are suggesting a script for
> > cherry-picking after the pull request has been merged? We could explore
> > this, but not sure it would add much over plain `git cherry-pick` for
> > typical AK usage. Given that, I am tempted to just allow both the current
> > merge script and the GitHub UI to be used. And after a period of a few
> > weeks/months, we can look at improvements based on actual experience. How
> > does that sound?
> >
> > Ismael
> >
> > On Mon, Dec 11, 2017 at 7:15 AM, Guozhang Wang <wa...@gmail.com>
> wrote:
> >
> > > Thanks Ismael for initiating this discussion. I am in favor for
> adopting
> > > Gitbox for its clean improvements since many of us have shared the pain
> > of
> > > managing PRs for long time.
> > >
> > > About this potential downsides, subjectively I feel these two arguments
> > are
> > > quite handle-able. The only concern I had about cherry-picking to other
> > > branches, which is a very common usage of the script tool we used
> today.
> > So
> > > I'd suggest simplifying that script to help with cherry-picking
> > (currently
> > > we only do up-stream cherry-picking, but we could also consider allow
> > both
> > > upstream and downstream cherry-picking) than completely discard it.
> > >
> > >
> > > Guozhang
> > >
> > > On Sat, Dec 9, 2017 at 11:39 PM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > >
> > > > One thing I forgot to mention, many projects have requested and been
> > > using
> > > > GitBox for a while:
> > > >
> > > > https://issues.apache.org/jira/browse/INFRA-15271?jql=
> > > > project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%
> > > > 20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%
> > > > 20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> > > >
> > > > On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk>
> > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > The Apache Infra team has started a new project earlier this year
> > > called
> > > > > GitBox that supports two-way synchronization between GitHub and
> > > > > git-wip-us.apache.org and, most importantly, provides GitHub write
> > > > access
> > > > > to committers. GitBox is not generally available yet, but
> individual
> > > > > projects can ask to be migrated.
> > > > >
> > > > > I think we should migrate kafka and kafka-site to GitBox. The main
> > > > benefit
> > > > > is that pull request management will be hugely improved for
> > committers:
> > > > >
> > > > > 1. Reviewers functionality will become available
> > > > >
> > > > > 2. Pull requests will be assignable to GitHub users
> > > > >
> > > > > 3. We will be able to assign labels to issues
> > > > >
> > > > > 4. We will be able to merge pull requests directly via GitHub
> instead
> > > of
> > > > > using the merge script
> > > > >
> > > > > 5. Committers will be able to close old and stale PRs
> > > > >
> > > > > 6. We will be able to use protected branches to restrict merges via
> > > > GitHub
> > > > > to only be allowed if tests pass and the PR has been approved by at
> > > least
> > > > > one committer
> > > > >
> > > > > A couple of potential downsides:
> > > > >
> > > > > 1. To avoid weird behaviour (even though two way synchronization
> > > exists),
> > > > > we'd want all committers to always push to GitHub, but this won't
> be
> > > > > enforced. That is, git-wip-us.apache.org will still be writable.
> > Given
> > > > > the small number of active committers, this seems to be a minor
> > issue.
> > > > >
> > > > > 2. If we decide to drop the merge script in favour of GitHub, some
> of
> > > the
> > > > > functionality will have to be done manually. GitHub supports
> "squash
> > > and
> > > > > merge" via the UI, so the main things that will have to be done
> > > manually
> > > > > are (1) Ensuring that the commit message follows the right format
> (2)
> > > > Close
> > > > > the JIRA ticket. I think this is OK, but we could allow both
> options
> > > > (merge
> > > > > and GitHub UI). If we want to allow both options, we'd just change
> > the
> > > > > default push repository in the script to be GitHub.
> > > > >
> > > > > All in all, I think this is a clear improvement and fixes a lot of
> > the
> > > > > pull request management pain points we've been facing. Given that,
> > I'd
> > > > like
> > > > > to move quickly, if possible.
> > > > >
> > > > > Please share your thoughts below and if people are in favour, I'll
> > > start
> > > > a
> > > > > vote.
> > > > >
> > > > > Ismael
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>
>
>
> --
> -- Guozhang
>
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Guozhang Wang <wa...@gmail.com>.
Sounds good to me.
On Sun, Dec 10, 2017 at 10:14 PM, Ismael Juma <is...@juma.me.uk> wrote:
> Thanks Guozhang.
>
> Cherry-picking also occurred to me sometime after I sent the email and I
> agree that it's useful functionality.
>
> Do I understand correctly that you are suggesting a script for
> cherry-picking after the pull request has been merged? We could explore
> this, but not sure it would add much over plain `git cherry-pick` for
> typical AK usage. Given that, I am tempted to just allow both the current
> merge script and the GitHub UI to be used. And after a period of a few
> weeks/months, we can look at improvements based on actual experience. How
> does that sound?
>
> Ismael
>
> On Mon, Dec 11, 2017 at 7:15 AM, Guozhang Wang <wa...@gmail.com> wrote:
>
> > Thanks Ismael for initiating this discussion. I am in favor for adopting
> > Gitbox for its clean improvements since many of us have shared the pain
> of
> > managing PRs for long time.
> >
> > About this potential downsides, subjectively I feel these two arguments
> are
> > quite handle-able. The only concern I had about cherry-picking to other
> > branches, which is a very common usage of the script tool we used today.
> So
> > I'd suggest simplifying that script to help with cherry-picking
> (currently
> > we only do up-stream cherry-picking, but we could also consider allow
> both
> > upstream and downstream cherry-picking) than completely discard it.
> >
> >
> > Guozhang
> >
> > On Sat, Dec 9, 2017 at 11:39 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > One thing I forgot to mention, many projects have requested and been
> > using
> > > GitBox for a while:
> > >
> > > https://issues.apache.org/jira/browse/INFRA-15271?jql=
> > > project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%
> > > 20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%
> > > 20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > >
> > > > Hi all,
> > > >
> > > > The Apache Infra team has started a new project earlier this year
> > called
> > > > GitBox that supports two-way synchronization between GitHub and
> > > > git-wip-us.apache.org and, most importantly, provides GitHub write
> > > access
> > > > to committers. GitBox is not generally available yet, but individual
> > > > projects can ask to be migrated.
> > > >
> > > > I think we should migrate kafka and kafka-site to GitBox. The main
> > > benefit
> > > > is that pull request management will be hugely improved for
> committers:
> > > >
> > > > 1. Reviewers functionality will become available
> > > >
> > > > 2. Pull requests will be assignable to GitHub users
> > > >
> > > > 3. We will be able to assign labels to issues
> > > >
> > > > 4. We will be able to merge pull requests directly via GitHub instead
> > of
> > > > using the merge script
> > > >
> > > > 5. Committers will be able to close old and stale PRs
> > > >
> > > > 6. We will be able to use protected branches to restrict merges via
> > > GitHub
> > > > to only be allowed if tests pass and the PR has been approved by at
> > least
> > > > one committer
> > > >
> > > > A couple of potential downsides:
> > > >
> > > > 1. To avoid weird behaviour (even though two way synchronization
> > exists),
> > > > we'd want all committers to always push to GitHub, but this won't be
> > > > enforced. That is, git-wip-us.apache.org will still be writable.
> Given
> > > > the small number of active committers, this seems to be a minor
> issue.
> > > >
> > > > 2. If we decide to drop the merge script in favour of GitHub, some of
> > the
> > > > functionality will have to be done manually. GitHub supports "squash
> > and
> > > > merge" via the UI, so the main things that will have to be done
> > manually
> > > > are (1) Ensuring that the commit message follows the right format (2)
> > > Close
> > > > the JIRA ticket. I think this is OK, but we could allow both options
> > > (merge
> > > > and GitHub UI). If we want to allow both options, we'd just change
> the
> > > > default push repository in the script to be GitHub.
> > > >
> > > > All in all, I think this is a clear improvement and fixes a lot of
> the
> > > > pull request management pain points we've been facing. Given that,
> I'd
> > > like
> > > > to move quickly, if possible.
> > > >
> > > > Please share your thoughts below and if people are in favour, I'll
> > start
> > > a
> > > > vote.
> > > >
> > > > Ismael
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
--
-- Guozhang
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Ismael Juma <is...@juma.me.uk>.
Thanks Guozhang.
Cherry-picking also occurred to me sometime after I sent the email and I
agree that it's useful functionality.
Do I understand correctly that you are suggesting a script for
cherry-picking after the pull request has been merged? We could explore
this, but not sure it would add much over plain `git cherry-pick` for
typical AK usage. Given that, I am tempted to just allow both the current
merge script and the GitHub UI to be used. And after a period of a few
weeks/months, we can look at improvements based on actual experience. How
does that sound?
Ismael
On Mon, Dec 11, 2017 at 7:15 AM, Guozhang Wang <wa...@gmail.com> wrote:
> Thanks Ismael for initiating this discussion. I am in favor for adopting
> Gitbox for its clean improvements since many of us have shared the pain of
> managing PRs for long time.
>
> About this potential downsides, subjectively I feel these two arguments are
> quite handle-able. The only concern I had about cherry-picking to other
> branches, which is a very common usage of the script tool we used today. So
> I'd suggest simplifying that script to help with cherry-picking (currently
> we only do up-stream cherry-picking, but we could also consider allow both
> upstream and downstream cherry-picking) than completely discard it.
>
>
> Guozhang
>
> On Sat, Dec 9, 2017 at 11:39 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > One thing I forgot to mention, many projects have requested and been
> using
> > GitBox for a while:
> >
> > https://issues.apache.org/jira/browse/INFRA-15271?jql=
> > project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%
> > 20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%
> > 20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > Hi all,
> > >
> > > The Apache Infra team has started a new project earlier this year
> called
> > > GitBox that supports two-way synchronization between GitHub and
> > > git-wip-us.apache.org and, most importantly, provides GitHub write
> > access
> > > to committers. GitBox is not generally available yet, but individual
> > > projects can ask to be migrated.
> > >
> > > I think we should migrate kafka and kafka-site to GitBox. The main
> > benefit
> > > is that pull request management will be hugely improved for committers:
> > >
> > > 1. Reviewers functionality will become available
> > >
> > > 2. Pull requests will be assignable to GitHub users
> > >
> > > 3. We will be able to assign labels to issues
> > >
> > > 4. We will be able to merge pull requests directly via GitHub instead
> of
> > > using the merge script
> > >
> > > 5. Committers will be able to close old and stale PRs
> > >
> > > 6. We will be able to use protected branches to restrict merges via
> > GitHub
> > > to only be allowed if tests pass and the PR has been approved by at
> least
> > > one committer
> > >
> > > A couple of potential downsides:
> > >
> > > 1. To avoid weird behaviour (even though two way synchronization
> exists),
> > > we'd want all committers to always push to GitHub, but this won't be
> > > enforced. That is, git-wip-us.apache.org will still be writable. Given
> > > the small number of active committers, this seems to be a minor issue.
> > >
> > > 2. If we decide to drop the merge script in favour of GitHub, some of
> the
> > > functionality will have to be done manually. GitHub supports "squash
> and
> > > merge" via the UI, so the main things that will have to be done
> manually
> > > are (1) Ensuring that the commit message follows the right format (2)
> > Close
> > > the JIRA ticket. I think this is OK, but we could allow both options
> > (merge
> > > and GitHub UI). If we want to allow both options, we'd just change the
> > > default push repository in the script to be GitHub.
> > >
> > > All in all, I think this is a clear improvement and fixes a lot of the
> > > pull request management pain points we've been facing. Given that, I'd
> > like
> > > to move quickly, if possible.
> > >
> > > Please share your thoughts below and if people are in favour, I'll
> start
> > a
> > > vote.
> > >
> > > Ismael
> > >
> > >
> >
>
>
>
> --
> -- Guozhang
>
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Guozhang Wang <wa...@gmail.com>.
Thanks Ismael for initiating this discussion. I am in favor for adopting
Gitbox for its clean improvements since many of us have shared the pain of
managing PRs for long time.
About this potential downsides, subjectively I feel these two arguments are
quite handle-able. The only concern I had about cherry-picking to other
branches, which is a very common usage of the script tool we used today. So
I'd suggest simplifying that script to help with cherry-picking (currently
we only do up-stream cherry-picking, but we could also consider allow both
upstream and downstream cherry-picking) than completely discard it.
Guozhang
On Sat, Dec 9, 2017 at 11:39 PM, Ismael Juma <is...@juma.me.uk> wrote:
> One thing I forgot to mention, many projects have requested and been using
> GitBox for a while:
>
> https://issues.apache.org/jira/browse/INFRA-15271?jql=
> project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%
> 20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%
> 20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
>
> On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > Hi all,
> >
> > The Apache Infra team has started a new project earlier this year called
> > GitBox that supports two-way synchronization between GitHub and
> > git-wip-us.apache.org and, most importantly, provides GitHub write
> access
> > to committers. GitBox is not generally available yet, but individual
> > projects can ask to be migrated.
> >
> > I think we should migrate kafka and kafka-site to GitBox. The main
> benefit
> > is that pull request management will be hugely improved for committers:
> >
> > 1. Reviewers functionality will become available
> >
> > 2. Pull requests will be assignable to GitHub users
> >
> > 3. We will be able to assign labels to issues
> >
> > 4. We will be able to merge pull requests directly via GitHub instead of
> > using the merge script
> >
> > 5. Committers will be able to close old and stale PRs
> >
> > 6. We will be able to use protected branches to restrict merges via
> GitHub
> > to only be allowed if tests pass and the PR has been approved by at least
> > one committer
> >
> > A couple of potential downsides:
> >
> > 1. To avoid weird behaviour (even though two way synchronization exists),
> > we'd want all committers to always push to GitHub, but this won't be
> > enforced. That is, git-wip-us.apache.org will still be writable. Given
> > the small number of active committers, this seems to be a minor issue.
> >
> > 2. If we decide to drop the merge script in favour of GitHub, some of the
> > functionality will have to be done manually. GitHub supports "squash and
> > merge" via the UI, so the main things that will have to be done manually
> > are (1) Ensuring that the commit message follows the right format (2)
> Close
> > the JIRA ticket. I think this is OK, but we could allow both options
> (merge
> > and GitHub UI). If we want to allow both options, we'd just change the
> > default push repository in the script to be GitHub.
> >
> > All in all, I think this is a clear improvement and fixes a lot of the
> > pull request management pain points we've been facing. Given that, I'd
> like
> > to move quickly, if possible.
> >
> > Please share your thoughts below and if people are in favour, I'll start
> a
> > vote.
> >
> > Ismael
> >
> >
>
--
-- Guozhang
Re: [DISCUSS] Allowing write access to GitHub repositories
Posted by Ismael Juma <is...@juma.me.uk>.
One thing I forgot to mention, many projects have requested and been using
GitBox for a while:
https://issues.apache.org/jira/browse/INFRA-15271?jql=project%20%3D%20INFRA%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20component%20%3D%20GitBox%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
On Sun, Dec 10, 2017 at 9:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
> Hi all,
>
> The Apache Infra team has started a new project earlier this year called
> GitBox that supports two-way synchronization between GitHub and
> git-wip-us.apache.org and, most importantly, provides GitHub write access
> to committers. GitBox is not generally available yet, but individual
> projects can ask to be migrated.
>
> I think we should migrate kafka and kafka-site to GitBox. The main benefit
> is that pull request management will be hugely improved for committers:
>
> 1. Reviewers functionality will become available
>
> 2. Pull requests will be assignable to GitHub users
>
> 3. We will be able to assign labels to issues
>
> 4. We will be able to merge pull requests directly via GitHub instead of
> using the merge script
>
> 5. Committers will be able to close old and stale PRs
>
> 6. We will be able to use protected branches to restrict merges via GitHub
> to only be allowed if tests pass and the PR has been approved by at least
> one committer
>
> A couple of potential downsides:
>
> 1. To avoid weird behaviour (even though two way synchronization exists),
> we'd want all committers to always push to GitHub, but this won't be
> enforced. That is, git-wip-us.apache.org will still be writable. Given
> the small number of active committers, this seems to be a minor issue.
>
> 2. If we decide to drop the merge script in favour of GitHub, some of the
> functionality will have to be done manually. GitHub supports "squash and
> merge" via the UI, so the main things that will have to be done manually
> are (1) Ensuring that the commit message follows the right format (2) Close
> the JIRA ticket. I think this is OK, but we could allow both options (merge
> and GitHub UI). If we want to allow both options, we'd just change the
> default push repository in the script to be GitHub.
>
> All in all, I think this is a clear improvement and fixes a lot of the
> pull request management pain points we've been facing. Given that, I'd like
> to move quickly, if possible.
>
> Please share your thoughts below and if people are in favour, I'll start a
> vote.
>
> Ismael
>
>