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 <damian....@gmail.com> wrote: > +1 > > On Tue, 12 Dec 2017 at 10:20 Rajini Sivaram <rajinisiva...@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 <wangg...@gmail.com> > wrote: > > > > > Sounds good to me. > > > > > > On Sun, Dec 10, 2017 at 10:14 PM, Ismael Juma <ism...@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 <wangg...@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 <ism...@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 <ism...@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 > > > > > >
