I had similar views on A actually. JIRA is pretty powerful, queryable. But, I convinced myself on labelling and then building out dashboards using SQL (for reports/analytics). Still having one place for issues/prs. For releases, we can directly leverage milestones.
We can definitely prioritize B first. Seems like everyone is on-board for that. @raymond : I am not sure if we will be able to install this on to the apache organization. Has been an issue for many of these github related services. On Sat, Jul 3, 2021 at 1:00 PM Raymond Xu <xu.shiyan.raym...@gmail.com> wrote: > Just to mention there are some GitHub plugin brings JIRA features to GH > issues. This one for example is free for open source. > https://www.zenhub.com/pricing > > > > On Fri, Jul 2, 2021 at 8:58 PM Navi Brar <navinder_b...@yahoo.com.invalid> > wrote: > > > Hi, > > > > > > +1 on B > > > > > > But I have a slightly orthogonal view on A. I think jira should stay. It > > provides a lot more visibility on the issue management. You can link PRs, > > wikis, releases etc easily which everyone will have to dig through the > > comments in github or every github issue might end up having too many > > labels that they might loose the significance. I recently landed a jira > on > > Hudi and I think the integration with github was pretty seamless. > > > > > > Happy either ways though. > > > > > > Thanks, > > > > Navinder > > > > > > > > On 03-Jul-2021, at 8:12 AM, vbal...@apache.org wrote: > > > > > > +1 for both A and B. Makes sense to centralize bug tracking and RFCs > > in github. > > > Balaji.V > > > > > > > > > On Friday, July 2, 2021, 06:44:06 PM PDT, Vinoth Chandar < > > vin...@apache.org> wrote: > > > > > > Raymond - +1 on your thoughts. > > > > > > Once we have more voices and alignment, we can do one final RFC on > cWiki > > > covering everything. > > > > > > Can more people please chime in. Ideally we will put this to a VOTE > > > > > >> On Fri, Jul 2, 2021 at 12:54 PM Raymond Xu < > xu.shiyan.raym...@gmail.com > > > > > >> wrote: > > >> > > >> +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 > <pwa...@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 <vin...@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 > > >>>> > > >>> > > >> > > > > >
