Before we could merge directly on Github the way we (committers) closed PRs was by using a script that would close the Jira ticket and set the fix version at the same time.
Somewhat annoyingly you can't (or we don't have permission to) set the fix version on a closed Jira ticket. We can probably ask for permission to edit closed/resolved Jira tickets in the AIRFLOW project, which would remove some of the pain here. I've asked for that https://issues.apache.org/jira/browse/INFRA-17033 Thanks for finding the issues to close btw, it's helpful. -ash > On 18 Sep 2018, at 12:33, Deng Xiaodong <xd.den...@gmail.com> wrote: > > Hi, > > Regarding your 2nd point, I think one of the reasons for what the > committers are not using hook to automatically close JIRA ticket after PR > merged is that they need to set fix version for each ticket. > > XD > > > On Tue, Sep 18, 2018 at 17:17 Юли Волкова <xnuins...@gmail.com > <mailto:xnuins...@gmail.com>> wrote: > >> Hi, Sid, thanks for some clarification about JIRA. At now, I walking >> through jira's task and ask Ash or other guys with admins right to close >> issues (for example: >> >> https://issues.apache.org/jira/browse/AIRFLOW-307?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel >> ), >> because PRs was successful merged 2 years ago. I would like to help in this >> scope: 1) If I have same moderators rights I can close tickets by myself >> 2) JIRA is a powerful tool on about integration - question only in do we >> have admin rights to add different integrations and triggers-hooks to JIRA. >> First of all, I propose to create hook what close task after PR was merged >> in master. Many task are open without any status changing with already >> merged PRs. >> >> On Tue, Sep 18, 2018 at 11:58 AM Sid Anand <san...@apache.org> wrote: >> >>> Hi Folks! >>> For some history, Airlfow started on GH issues. We also had a very >> popular >>> Google group. When we moved to Apache, we were told that Jira was the way >>> we needed to go for issue tracking because it resided on Apache >>> infrastructure. When we moved over, we had to drop 100+ GH issues on the >>> floor -- there was no way to transfer them to Jira and maintain the >>> original submitter/owner info since there was no mapping of users between >>> the 2 systems. >>> >>> Here's a pie chart of our existing issues by status: >>> >>> >> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023&statistictype=statuses&selectedProjectId=12320023&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED|a85ff737799378265f90bab4f1456b5e2811a507|lin&Next=Next >> <https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023&statistictype=statuses&selectedProjectId=12320023&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7Ca85ff737799378265f90bab4f1456b5e2811a507%7Clin&Next=Next> >>> < >> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023&statistictype=statuses&selectedProjectId=12320023&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7Ca85ff737799378265f90bab4f1456b5e2811a507%7Clin&Next=Next >> >> <https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023&statistictype=statuses&selectedProjectId=12320023&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7Ca85ff737799378265f90bab4f1456b5e2811a507%7Clin&Next=Next> >>> >>> >>> I'm attaching a screen shot as well. >>> >>> [image: Screenshot 2018-09-16 11.28.57.png] >>> >>> I think we all agree that there is better integration between GH PRs and >>> GH Issues than between GH PRs and Jira issues. >>> >>> There are some practical matters to consider: >>> >>> - For the 1100-1200 unclosed/unresolved issues, how will we transfer >>> them to GH or will we drop those on the floor? How would we map >> submitters >>> between the 2 systems, and how would we transfer the >> content/comments,etc... >>> - For the existing closed PRs (>3k), whose PRs reference JIRA, we'd >>> need to keep JIRA around in read-only mode so we could reference the >>> bug/feature details, but somehow disallow new JIRA creations, lest >> some >>> people continue to use it to create new issues >>> - I'm assuming the GH issue naming would not conflict with that of >>> JIRA naming in commit message subjects and PRs. In other words, >>> incubator-airlow-1 vs AIRFLOW-1 or airflow-1 vs AIRFLOW-1 or possibly >>> conflict at AIRFLOW-1? Once we graduate, I'm pretty sure the >> incubator name >>> will be dropped, so there may be a naming conflict. >>> >>> In the end, these are 2 different tools. The issues you raise are mainly >>> around governance. >>> >>> If you folks would like to propose a new means to manage the JIRAs, can >>> you outline a solution on Wiki and drop a link into an email on this >> list? >>> We can then raise a vote. >>> >>> IMHO, our community would scale the best if more people picked up >>> responsibilities such as these. Grooming/Organizing JIRAs doesn't need to >>> be a responsibility owned by the maintainers. Anyone can take the lead on >>> discussions, etc... >>> >>> -s >>> >>> On Mon, Sep 17, 2018 at 2:09 AM Sumit Maheshwari <sumeet.ma...@gmail.com >>> >>> wrote: >>> >>>> Strong +1 for moving to GitHub from Jira. >>>> >>>> On Mon, Sep 17, 2018 at 12:35 PM George Leslie-Waksman < >> waks...@gmail.com >>>>> >>>> wrote: >>>> >>>>> Are there Apache rules preventing us from switching to GitHub Issues? >>>>> >>>>> That seems like it might better fit much of Airflow's user base. >>>>> >>>>> >>>>> On Sun, Sep 16, 2018, 9:21 AM Jeff Payne <jpa...@bombora.com> wrote: >>>>> >>>>>> I agree that Jira could be better utilized. I read the original >>>>>> conversation on the mailing list about how Jira should be used (or >> if >>>> it >>>>>> should be used at all) and I'm still unclear about why it was picked >>>> over >>>>>> just using github issues. It refers to a dashboard, which I've yet >> to >>>>>> investigate, but Jira is much more than just dashboards. >>>>>> >>>>>> If this project is going to use Jira, then: >>>>>> >>>>>> 1) It would be great to see moderation and labeling of the Jira >>>> issues by >>>>>> the main contributors to make it easier for people to break into >>>>>> contributing. >>>>>> 2) It would also be nice if the initial conversation of whether or >>>> not an >>>>>> issue warrants development at all happened on the Jira issue, or at >>>> least >>>>>> some acknowledgement by the main contributors. >>>>>> 3) Larger enhancements and efforts or vague suggestions still get >>>>>> discussed on the dev mailing list before a Jira is even opened, but >>>> after >>>>>> that, the discussion moves to the Jira, with a link back to the >>>> mailing >>>>>> list email for reference. >>>>>> 4) The discussion on the PR is only concerned with HOW the >> change/fix >>>> is >>>>>> implemented. >>>>>> >>>>>> Get Outlook for Android<https://aka.ms/ghei36> >>>>>> >>>>>> ________________________________ >>>>>> From: James Meickle <jmeic...@quantopian.com.INVALID> >>>>>> Sent: Sunday, September 16, 2018 7:46:58 AM >>>>>> To: d...@airflow.apache.org >>>>>> Subject: Re: It's very hard to become a committer on the project >>>>>> >>>>>> Definitely agree with this. I'm not always opposed to JIRA for >>>> projects, >>>>>> but the way it's being used for this project makes it very hard to >>>> break >>>>>> into contributing. The split between GH and JIRA is also painful >> since >>>>>> there's no automatic integration of them. >>>>>> >>>>>> On Sun, Sep 16, 2018 at 9:29 AM airflowuser >>>>>> <airflowu...@protonmail.com.invalid> wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> I'm struggling finding tickets to address and while discussing it >> on >>>>> chat >>>>>>> others reported they had the same problem when they began working >> on >>>>> the >>>>>>> project. >>>>>>> >>>>>>> The problem is due to: >>>>>>> 1. It's very hard to locate tickets on Jira. The categories are a >>>> mess, >>>>>>> versions are not enforced. each use can tag,label and set priority >>>> at >>>>> his >>>>>>> will. No one monitor or overwrite it >>>>>>> 2. It's impossible for a new committer to find issues which can >> be >>>>>>> easy-fix and a "good first issue". >>>>>>> >>>>>>> My suggestions: >>>>>>> 1. Looking at the ticket system there are usually less than 10 new >>>>>> tickets >>>>>>> a day. It won't take too much time for someone with knowledge on >> the >>>>>>> project to properly tag the ticket. >>>>>>> >>>>>>> 2. I think that most of you don't even check the Jira. Most of you >>>>> submit >>>>>>> PRs and 5 seconds before opening a ticket (just because you must). >>>>> There >>>>>> is >>>>>>> no doubt that the Jira is a "side" system which doesn't really >>>> perform >>>>>> it's >>>>>>> job. >>>>>>> >>>>>>> Take a look at this: >>>>>>> >> https://issues.apache.org/jira/projects/AIRFLOW/issues/AIRFLOW-2999 >>>>>>> a member of the community asks for committers for input but no one >>>>>>> replies. I doubt this is because no one has input.. I am sure that >>>> if a >>>>>> PR >>>>>>> was submitted you had comments. It's simply because you don't see >>>> it. >>>>>> This >>>>>>> is why I think the current Jira does't function properly. I think >>>> that >>>>>>> Github can perform a better role. All of you as committers are >>>> already >>>>>>> there and it's always better to work with one system rather with >>>> two. >>>>> The >>>>>>> colors and labels of the GitHub as very easy to notice. >>>>>>> >>>>>>> Either way, what ever you decide something needs to be change. >>>> Either >>>>>> Jira >>>>>>> will be more informative or move to GitHub. >>>>>>> >>>>>>> Thank you all for your good work :) >>>>>> >>>>> >>>> >>> >> >> -- >> _________ >> >> С уважением, Юлия Волкова >> Тел. : +7 (911) 116-71-82
