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 > <mailto:dongjoon.h...@gmail.com>> wrote: > Thank you, Hyukjin ! > > On Sun, Jun 16, 2019 at 4:12 PM Hyukjin Kwon <gurwls...@gmail.com > <mailto:gurwls...@gmail.com>> wrote: > Labels look good and useful. > > On Sat, 15 Jun 2019, 02:36 Dongjoon Hyun, <dongjoon.h...@gmail.com > <mailto: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 > <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 > <mailto:dongjoon.h...@gmail.com>> wrote: > Hi, All. > > JIRA and PR is ready for reviews. > > https://issues.apache.org/jira/browse/SPARK-28051 > <https://issues.apache.org/jira/browse/SPARK-28051> (Exposing JIRA issue > component types at GitHub PRs) > https://github.com/apache/spark/pull/24871 > <https://github.com/apache/spark/pull/24871> > > Bests, > Dongjoon. > > > On Thu, Jun 13, 2019 at 10:48 AM Dongjoon Hyun <dongjoon.h...@gmail.com > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <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.
