hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhavani Sudha <bhavanisud...@gmail.com>
Subject Re: [DISCUSS] Consolidate all dev collaboration to Github
Date Fri, 16 Jul 2021 05:49:52 GMT
Completely agree on B. On A I feel the necessity to centralize 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 <yanghua1127@gmail.com> wrote:

> +1 for option B.
>
> Best,
> Vino
>
> Sivabalan <n.siva.b@gmail.com> 于2021年7月16日周五 上午10:35写道:
>
> > +1 on B. Not sure on A though. I understand the intent to have all 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 <vinoth@apache.org>
> 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 the
> > tradeoffs
> > > there.
> > >
> > > On Fri, Jul 9, 2021 at 2:39 AM wei li <lw309637554@gmail.com> wrote:
> > >
> > > > +1
> > > >
> > > > On 2021/07/02 03:40:51, Vinoth Chandar <vinoth@apache.org> 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 to
> 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 management
> from
> > > > > boards.
> > > > >
> > > > > B) Our design docs are on cWiki. Even though we link it off the
> site,
> > > > from
> > > > > my experience, many do not discover them.
> > > > > For large PRs, we need to manually enforce that design and code 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 PRs
to
> > > raise
> > > > > RFCs and discuss them.
> > > > >
> > > > > This all also makes it easy for us to measure community activity
> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message