hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brahma Reddy Battula <bra...@apache.org>
Subject Re: [DISCUSS] Tips for improving productivity, workflow in the Hadoop project?
Date Thu, 15 Jul 2021 17:39:33 GMT
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, epayne@apache.org <epayne@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 <
> iwasakims@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
> <stevel@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 <aajisaka@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 <weichiu@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-unsubscribe@hadoop.apache.org
> >>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
> >>>
> >>>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>

-- 



--Brahma Reddy Battula

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