hudi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Xu <xu.shiyan.raym...@gmail.com>
Subject Re: [DISCUSS] Consolidate all dev collaboration to Github
Date Fri, 02 Jul 2021 19:53:58 GMT
+1 for both A and B

Also a related suggestion:
we can put the release notes and new feature highlights in the release
notes section in GitHub releases instead of separately writing them in the
asf-site


On Fri, Jul 2, 2021 at 11:25 AM Prashant Wason <pwason@uber.com.invalid>
wrote:

> +1 for complete Github migration. JIRA is too cumbersome and painful to
> use.
>
> Github PRs and wiki also improve visibility of the project and I think may
> increase community feedback and participation as its simpler to use.
>
> Prashant
>
>
> On Thu, Jul 1, 2021 at 8:41 PM 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
> >
>

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