From dev-return-4212-archive-asf-public=cust-asf.ponee.io@hudi.apache.org Sat Jul 17 03:31:47 2021 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org [3.227.148.255]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 425A6180648 for ; Sat, 17 Jul 2021 05:31:47 +0200 (CEST) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with SMTP id 77A8D3F698 for ; Sat, 17 Jul 2021 03:31:46 +0000 (UTC) Received: (qmail 2321 invoked by uid 500); 17 Jul 2021 03:31:46 -0000 Mailing-List: contact dev-help@hudi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hudi.apache.org Delivered-To: mailing list dev@hudi.apache.org Received: (qmail 2309 invoked by uid 99); 17 Jul 2021 03:31:45 -0000 Received: from mailrelay1-he-de.apache.org (HELO mailrelay1-he-de.apache.org) (116.203.21.61) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Jul 2021 03:31:45 +0000 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by mailrelay1-he-de.apache.org (ASF Mail Server at mailrelay1-he-de.apache.org) with ESMTPSA id 719873E823 for ; Sat, 17 Jul 2021 03:31:44 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id ee25so15479371edb.5 for ; Fri, 16 Jul 2021 20:31:44 -0700 (PDT) X-Gm-Message-State: AOAM531oTSOhzVBQ+WUUm4x2RovzIZ/ToZlvYQ+URfBoh9uefIjtACWQ tTan7/lJxP7HKXcCnJdOwRdOeHeswa9rc6ztff0= X-Google-Smtp-Source: ABdhPJzslNT8s1ooPutWrjeWEhaYLKsZZsGBrSOzNxae/dmQdCYpag4kzvSfeqfFcz2CuzWVpitgDJyMJjYRPJMnASs= X-Received: by 2002:a05:6402:358c:: with SMTP id y12mr18783587edc.329.1626492703997; Fri, 16 Jul 2021 20:31:43 -0700 (PDT) MIME-Version: 1.0 References: <0B3A9578-8C31-4444-A350-ED0B92BA6A58@gmail.com> In-Reply-To: From: Gary Li Date: Sat, 17 Jul 2021 11:31:32 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [DISCUSS] Consolidate all dev collaboration to Github To: dev@hudi.apache.org Content-Type: multipart/alternative; boundary="000000000000da00df05c749574f" --000000000000da00df05c749574f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for option B. On Sat, Jul 17, 2021 at 9:51 AM Udit Mehrotra wrote: > +1 for option B. For A, I will need more data points to convince myself i= f > GitHub issues will provide all the issue tracking functionality that Jira > provides today. > > Thanks, > Udit > > On Fri, Jul 16, 2021 at 2:33 PM Vinoth Chandar wrote: > > > Looks like we can start with B has a lot of support. > > I will start a VOTE on B alone and we can proceed if the VOTE passes. > > > > On Fri, Jul 16, 2021 at 8:05 AM Nishith wrote: > > > > > +1 for option B. > > > > > > > On Jul 15, 2021, at 10:50 PM, Bhavani Sudha > > > > wrote: > > > > > > > > =EF=BB=BFCompletely agree on B. On A I feel the necessity to centra= lize > > > everything > > > > in one place but also without losing the capabilities of Jira. I > think > > we > > > > will have to explore tools in eitherways. > > > > > > > > Thanks, > > > > Sudha > > > > > > > >> On Thu, Jul 15, 2021 at 10:42 PM vino yang > > > wrote: > > > >> > > > >> +1 for option B. > > > >> > > > >> Best, > > > >> Vino > > > >> > > > >> Sivabalan =E4=BA=8E2021=E5=B9=B47=E6=9C=8816= =E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8A=E5=8D=8810:35=E5=86=99=E9=81=93=EF=BC= =9A > > > >> > > > >>> +1 on B. Not sure on A though. I understand the intent to have al= l > in > > > >>> one place. but not very sure if we can get all functionality > > (version, > > > >>> type, component, status, parent- child relation), etc ported over > to > > > >>> github. I assume labels are the only option we have to achieve > these. > > > >>> Probably, we should also document the labels in detail so that > anyone > > > >>> looking to take a look at untriaged issues should know how/where = to > > > look > > > >>> at. If we plan to use GH issues for all, I am sure there will be = a > > lot > > > of > > > >>> proliferation of issues. > > > >>> > > > >>> On Fri, Jul 9, 2021 at 12:29 PM Vinoth Chandar > > > >> wrote: > > > >>> > > > >>>> Based on this, I will start consolidating more of the cWiki > content > > to > > > >>>> github wiki and master branch? > > > >>>> > > > >>>> JIRA vs GH Issue still probably needs more feedback. I do see th= e > > > >>> tradeoffs > > > >>>> there. > > > >>>> > > > >>>> On Fri, Jul 9, 2021 at 2:39 AM wei li > > wrote: > > > >>>> > > > >>>>> +1 > > > >>>>> > > > >>>>> On 2021/07/02 03:40:51, Vinoth Chandar > wrote: > > > >>>>>> Hi all, > > > >>>>>> > > > >>>>>> When we incubated Hudi, we made some initial choices around > > > >>>> collaboration > > > >>>>>> tools of choice. I am wondering if there are still optimal, > given > > > >> the > > > >>>>> scale > > > >>>>>> of the community at this point. > > > >>>>>> > > > >>>>>> Specifically, two points. > > > >>>>>> > > > >>>>>> A) Our issue tracker is JIRA, while we just use Github Issues > for > > > >>>> support > > > >>>>>> triage. While JIRA is pretty advanced and gives us the ability > to > > > >>> track > > > >>>>>> releases, versions and kanban boards, there are few practical > > > >>>> operational > > > >>>>>> problems. > > > >>>>>> > > > >>>>>> - Developers often open bug fixes/PR which all need to be > > > >>> continuously > > > >>>>>> tagged against a release version (fix version) > > > >>>>>> - Referencing JIRAs from Pull Requests is great (we cannot do > > > >> things > > > >>>> like > > > >>>>>> `fixes #1234` to close issues when PR lands, not an easy way t= o > > > >> click > > > >>>> and > > > >>>>>> get to the JIRA) > > > >>>>>> - Many more developers have a github account, to contribute to > > Hudi > > > >>>>> though, > > > >>>>>> they need an additional sign-up on jira. > > > >>>>>> > > > >>>>>> So wondering if we should just use one thing - Github Issues, > and > > > >>> build > > > >>>>>> scripts/hubot or something to get the missing project manageme= nt > > > >> from > > > >>>>>> boards. > > > >>>>>> > > > >>>>>> B) Our design docs are on cWiki. Even though we link it off th= e > > > >> site, > > > >>>>> from > > > >>>>>> my experience, many do not discover them. > > > >>>>>> For large PRs, we need to manually enforce that design and cod= e > > are > > > >>> in > > > >>>>> sync > > > >>>>>> before we land. If we can, I would love to make RFC being in > good > > > >>>> shape a > > > >>>>>> pre-requisite for landing the PR. > > > >>>>>> Once again, separate signup is needed to write design docs or > > > >> comment > > > >>>> on > > > >>>>>> them. > > > >>>>>> > > > >>>>>> So, wondering if we can move our process docs etc into Github > Wiki > > > >>> and > > > >>>>> RFCs > > > >>>>>> to the master branch in a rfc folder, and we just use github P= Rs > > to > > > >>>> raise > > > >>>>>> RFCs and discuss them. > > > >>>>>> > > > >>>>>> This all also makes it easy for us to measure community activi= ty > > > >> and > > > >>>> keep > > > >>>>>> streamlining our processes. > > > >>>>>> > > > >>>>>> personally, these different channels are overwhelming to me > > > >> at-least > > > >>> :) > > > >>>>>> > > > >>>>>> Love to hear thoughts. Please specify if you are for,against > each > > > >> of > > > >>> A > > > >>>>> and > > > >>>>>> B. > > > >>>>>> > > > >>>>>> > > > >>>>>> Thanks > > > >>>>>> Vinoth > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >>> -- > > > >>> Regards, > > > >>> -Sivabalan > > > >>> > > > >> > > > > > > --000000000000da00df05c749574f--