I agree with Ahmed Hussein…Jira should not be used for number generation..
We can always revisit the jira to see useful discussion at one place… @wei-chu, +1 on proposal for cleaning the PR’s.. On Thu, 15 Jul 2021 at 9:15 PM, epa...@apache.org <epa...@apache.org> wrote: > > I usually use PR comments to discuss about the patch submitted. > My concern is that still leaves multiple places to look in order to get a > full picture of an issue. > -Eric > > On Wednesday, July 14, 2021, 7:07:30 PM CDT, Masatake Iwasaki < > iwasak...@oss.nttdata.co.jp> wrote: > > > - recently, JIRA became some sort of a "number generator" with > insufficient > > description/details as the > > developers and the reviewers spending more time discussing in the PR. > > JIRA issues contain useful information in the fields. > We are leveraging them in development and release process. > > * https://yetus.apache.org/documentation/0.13.0/releasedocmaker/ > * > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336122 > > I usually use PR comments to discuss about the patch submitted. > JIRA comments are used for background or design discussion before and > after submitting PR. > There would be no problem having no comment in minor/trivial JIRA issues. > > > On 2021/07/14 23:50, Ahmed Hussein wrote: > > Do you consider migrating Jira issues to Github issues? > > > > I am a little bit concerned that there are some committers who still > prefer > > Jira-precommits over GitHub PR > > (P.S. I am not a committer). > > > > Their point is that Github-PR confuses them with discussions/comments > being > > in two places rather than one. > > > > Personally, I found several Github-PRs comments discussing the validity > of > > the feature/bug. > > As a result: > > - recently, JIRA became some sort of a "number generator" with > insufficient > > description/details as the > > developers and the reviewers spending more time discussing in the PR. > > - the relation between a single Jira and Github-PR is 1-to-M. In order to > > find related discussions, the user may > > need to visit every PR (that may include closed ones) > > > > > > > > On Wed, Jul 14, 2021 at 8:46 AM Steve Loughran > <ste...@cloudera.com.invalid> > > wrote: > > > >> not sure about stale PR closing; when you've a patch which is still > pending > >> review it's not that fun to have it closed. > >> > >> maybe better to have review sessions. I recall many, many years ago > >> attempts to try and catch up with all outstanding patch reviews. > >> > >> > >> > >> > >> On Wed, 14 Jul 2021 at 03:00, Akira Ajisaka <aajis...@apache.org> > wrote: > >> > >>> Thank you Wei-Chiu for starting the discussion, > >>> > >>>> 3. JIRA security > >>> I'm +1 to use private JIRA issues to handle vulnerabilities. > >>> > >>>> 5. Doc update > >>> +1, I build the document daily and it helps me fixing documents: > >>> https://aajisaka.github.io/hadoop-document/ It's great if the latest > >>> document is built and published by the Apache Hadoop community. > >>> > >>> My idea related to GitHub PR: > >>> 1. Disable the precommit jobs for JIRA, always use GitHub PR. It saves > >>> costs to configure and debug the precommit jobs. > >>> https://issues.apache.org/jira/browse/HADOOP-17798 > >>> 2. Improve the pull request template for the contributors > >>> https://issues.apache.org/jira/browse/HADOOP-17799 > >>> > >>> Regards, > >>> Akira > >>> > >>> On Tue, Jul 13, 2021 at 12:35 PM Wei-Chiu Chuang <weic...@apache.org> > >>> wrote: > >>>> > >>>> I work on multiple projects and learned a bunch from those > >> projects.There > >>>> are nice add-ons that help with productivity. There are things we can > >> do > >>> to > >>>> help us manage the project better. > >>>> > >>>> 1. Add new issue types. > >>>> We can add "Epic" jira type to organize a set of related jiras. This > >>> could > >>>> be easier to manage than using a regular JIRA and call it "umbrella". > >>>> > >>>> 2. GitHub Actions > >>>> I am seeing more projects moving to GitHub Actions for precommits. We > >>> don't > >>>> necessarily need to migrate off Jenkins, but there are nice add-ons > >> that > >>>> can perform static analysis, catching potential issues. For example, > >>> Ozone > >>>> adds SonarQube to post-commit, and exports the report to SonarCloud. > >>> Other > >>>> add-ons are available to scan for docker images, vulnerabilities > scans. > >>>> > >>>> 3. JIRA security > >>>> It is possible to set up security level (public/private) in JIRA. This > >>> can > >>>> be used to track vulnerability issues and be made only visible to > >>>> committers. Example: INFRA-15258 > >>>> <https://issues.apache.org/jira/browse/INFRA-15258> > >>>> > >>>> 4. New JIRA fields > >>>> It's possible to add new fields. For example, we can add a "Reviewer" > >>>> field, which could help improve the attention to issues. > >>>> > >>>> 5. Doc update > >>>> It is possible to set up automation such that the doc on the Hadoop > >>> website > >>>> is refreshed for every commit, providing the latest doc to the public. > >>>> > >>>> 6. Webhook > >>>> It's possible to set up webhook such that every commit in GitHub sends > >> a > >>>> notification to the ASF slack. It can be used for other kinds of > >>>> automation. Sky's the limit. > >>>> > >>>> Thoughts? What else can do we? > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > >>> For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >>> > >>> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > > -- --Brahma Reddy Battula
