Does the label merged into the commit? Somehow it would be still good to see component in the msg.
G On Wed, Jun 19, 2019 at 11:09 AM Gengliang Wang <ltn...@gmail.com> wrote: > Hi Dongjoon, > > +1 with the nice work. > Quick question: if the github_jira_sync script is fully automated, should > contributors skip adding the duplicated labels in new PR titles? > > > On Jun 17, 2019, at 4:21 PM, Gabor Somogyi <gabor.g.somo...@gmail.com> > wrote: > > Dongjoon, I think it's useful. Thanks for adding it! > > On Mon, Jun 17, 2019 at 8:05 AM Dongjoon Hyun <dongjoon.h...@gmail.com> > wrote: > >> Thank you, Hyukjin ! >> >> On Sun, Jun 16, 2019 at 4:12 PM Hyukjin Kwon <gurwls...@gmail.com> wrote: >> >>> Labels look good and useful. >>> >>> On Sat, 15 Jun 2019, 02:36 Dongjoon Hyun, <dongjoon.h...@gmail.com> >>> wrote: >>> >>>> Now, you can see the exposed component labels (ordered by the number of >>>> PRs) here and click the component to search. >>>> >>>> https://github.com/apache/spark/labels?sort=count-desc >>>> >>>> Dongjoon. >>>> >>>> >>>> On Fri, Jun 14, 2019 at 1:15 AM Dongjoon Hyun <dongjoon.h...@gmail.com> >>>> wrote: >>>> >>>>> Hi, All. >>>>> >>>>> JIRA and PR is ready for reviews. >>>>> >>>>> https://issues.apache.org/jira/browse/SPARK-28051 (Exposing JIRA >>>>> issue component types at GitHub PRs) >>>>> https://github.com/apache/spark/pull/24871 >>>>> >>>>> Bests, >>>>> Dongjoon. >>>>> >>>>> >>>>> On Thu, Jun 13, 2019 at 10:48 AM Dongjoon Hyun < >>>>> dongjoon.h...@gmail.com> wrote: >>>>> >>>>>> Thank you for the feedbacks and requirements, Hyukjin, Reynold, Marco. >>>>>> >>>>>> Sure, we can do whatever we want. >>>>>> >>>>>> I'll wait for more feedbacks and proceed to the next steps. >>>>>> >>>>>> Bests, >>>>>> Dongjoon. >>>>>> >>>>>> >>>>>> On Wed, Jun 12, 2019 at 11:51 PM Marco Gaido <marcogaid...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Dongjoon, >>>>>>> Thanks for the proposal! I like the idea. Maybe we can extend it to >>>>>>> component too and to some jira labels such as correctness which may be >>>>>>> worth to highlight in PRs too. My only concern is that in many cases >>>>>>> JIRAs >>>>>>> are created not very carefully so they may be incorrect at the moment of >>>>>>> the pr creation and it may be updated later: so keeping them in sync >>>>>>> may be >>>>>>> an extra effort.. >>>>>>> >>>>>>> On Thu, 13 Jun 2019, 08:09 Reynold Xin, <r...@databricks.com> wrote: >>>>>>> >>>>>>>> Seems like a good idea. Can we test this with a component first? >>>>>>>> >>>>>>>> On Thu, Jun 13, 2019 at 6:17 AM Dongjoon Hyun < >>>>>>>> dongjoon.h...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, All. >>>>>>>>> >>>>>>>>> Since we use both Apache JIRA and GitHub actively for Apache Spark >>>>>>>>> contributions, we have lots of JIRAs and PRs consequently. One >>>>>>>>> specific >>>>>>>>> thing I've been longing to see is `Jira Issue Type` in GitHub. >>>>>>>>> >>>>>>>>> How about exposing JIRA issue types at GitHub PRs as GitHub >>>>>>>>> `Labels`? There are two main benefits: >>>>>>>>> 1. It helps the communication between the contributors and >>>>>>>>> reviewers with more information. >>>>>>>>> (In some cases, some people only visit GitHub to see the PR >>>>>>>>> and commits) >>>>>>>>> 2. `Labels` is searchable. We don't need to visit Apache Jira to >>>>>>>>> search PRs to see a specific type. >>>>>>>>> (For example, the reviewers can see and review 'BUG' PRs first >>>>>>>>> by using `is:open is:pr label:BUG`.) >>>>>>>>> >>>>>>>>> Of course, this can be done automatically without human >>>>>>>>> intervention. Since we already have GitHub Jenkins job to access >>>>>>>>> JIRA/GitHub, that job can add the labels from the beginning. If >>>>>>>>> needed, I >>>>>>>>> can volunteer to update the script. >>>>>>>>> >>>>>>>>> To show the demo, I labeled several PRs manually. You can see the >>>>>>>>> result right now in Apache Spark PR page. >>>>>>>>> >>>>>>>>> - https://github.com/apache/spark/pulls >>>>>>>>> >>>>>>>>> If you're surprised due to those manual activities, I want to >>>>>>>>> apologize for that. I hope we can take advantage of the existing >>>>>>>>> GitHub >>>>>>>>> features to serve Apache Spark community in a way better than >>>>>>>>> yesterday. >>>>>>>>> >>>>>>>>> How do you think about this specific suggestion? >>>>>>>>> >>>>>>>>> Bests, >>>>>>>>> Dongjoon >>>>>>>>> >>>>>>>>> PS. I saw that `Request Review` and `Assign` features are already >>>>>>>>> used for some purposes, but these feature are out of the scope in this >>>>>>>>> email. >>>>>>>>> >>>>>>>> >