hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinoth Chandar <>
Subject [DISCUSS] Consolidate all dev collaboration to Github
Date Fri, 02 Jul 2021 03:40:51 GMT
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

- 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

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

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


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