- 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: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
