Re: Ask for ARM CI for spark

[Tianhua huang]

Thanks Sean.

I am very happy to hear that the community will put effort to fix the
ARM-related issues. I'd be happy to help if you like. And could you give
the trace link of this issue, then I can check it is fixed or not, thank
you.
As far as I know the old versions of spark support ARM, and now the new
versions don't, this just shows that we need a CI to check whether the
spark support ARM and whether some modification break it.
I will add a demo job in OpenLab to build spark on ARM and do a simple UT
test. Later I will give the job link.

Let me know what you think.

Thank you all!


On Wed, Jun 19, 2019 at 8:47 PM Sean Owen  wrote:

> I'd begin by reporting and fixing ARM-related issues in the build. If
> they're small, of course we should do them. If it requires significant
> modifications, we can discuss how much Spark can support ARM. I don't
> think it's yet necessary for the Spark project to run these CI builds
> until that point, but it's always welcome if people are testing that
> separately.
>
> On Wed, Jun 19, 2019 at 7:41 AM Holden Karau  wrote:
> >
> > Moving to dev@ for increased visibility among the developers.
> >
> > On Wed, Jun 19, 2019 at 1:24 AM Tianhua huang 
> wrote:
> >>
> >> Thanks for your reply.
> >>
> >> As I said before, I met some problem of build or test for spark on
> aarch64 server, so it will be better to have the ARM CI to make sure the
> spark is compatible for AArch64 platforms.
> >>
> >> I’m from OpenLab team(https://openlabtesting.org/ ,a community to do
> open source project testing. And we can support some Arm virtual machines
> to AMPLab Jenkins, and also we have a developer team that willing to work
> on this, we willing to maintain build CI jobs and address the CI issues.
> What do you think?
> >>
> >>
> >> Thanks for your attention.
> >>
> >>
> >> On Wed, Jun 19, 2019 at 6:39 AM shane knapp 
> wrote:
> >>>
> >>> yeah, we don't have any aarch64 systems for testing...  this has been
> asked before but is currently pretty low on our priority list as we don't
> have the hardware.
> >>>
> >>> sorry,
> >>>
> >>> shane
> >>>
> >>> On Mon, Jun 10, 2019 at 7:08 PM Tianhua huang <
> huangtianhua...@gmail.com> wrote:
> 
>  Hi, sorry to disturb you.
>  The CI testing for apache spark is supported by AMPLab Jenkins, and I
> find there are some computers(most of them are Linux (amd64) arch) for the
> CI development, but seems there is no Aarch64 computer for spark CI
> testing. Recently, I build and run test for spark(master and branch-2.4) on
> my arm server, and unfortunately there are some problems, for example, ut
> test is failed due to a LEVELDBJNI native package, the details for java
> test see http://paste.openstack.org/show/752063/ and python test see
> http://paste.openstack.org/show/752709/
>  So I have a question about the ARM CI testing for spark, is there any
> plan to support it? Thank you very much and I will wait for your reply!
> >>>
> >>>
> >>>
> >>> --
> >>> Shane Knapp
> >>> UC Berkeley EECS Research / RISELab Staff Technical Lead
> >>> https://rise.cs.berkeley.edu
> >
> >
> >
> > --
> > Twitter: https://twitter.com/holdenkarau
> > Books (Learning Spark, High Performance Spark, etc.):
> https://amzn.to/2MaRAG9
> > YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>

Re: Jenkins Jobs for Hadoop-3.2 profile

[Xiao Li]

Thank you, Shane!!!

Will do it next time. : )

On Wed, Jun 19, 2019 at 3:15 PM shane knapp  wrote:

> i will do it later this week.  also, in the future, please file jiras for
> stuff like this rather than pinging me on the list.  ;)
>
> On Wed, Jun 19, 2019 at 1:39 PM Xiao Li  wrote:
>
>> That sounds good to me!
>>
>> @shane knapp   Could you help this? Or Dongjoon can
>> do it by himself since he has the access?
>>
>> Cheers,
>>
>> Xiao
>>
>> On Wed, Jun 19, 2019 at 10:56 AM Dongjoon Hyun 
>> wrote:
>>
>>> Hi, All.
>>>
>>> So far, we have only `hadoop-2.7` profile jobs.
>>>
>>> - SBT with hadoop-2.7
>>> - Maven with hadoop-2.7 (on JDK8 and JDK11)
>>>
>>> Can we have a `Hadoop-3.2` profile Jenkins job for Spark 3.0.0?
>>>
>>> Bests,
>>> Dongjoon.
>>>
>>
>>
>> --
>> [image: Databricks Summit - Watch the talks]
>> 
>>
>
>
> --
> Shane Knapp
> UC Berkeley EECS Research / RISELab Staff Technical Lead
> https://rise.cs.berkeley.edu
>


-- 
[image: Databricks Summit - Watch the talks]

Re: Jenkins Jobs for Hadoop-3.2 profile

[shane knapp]

i will do it later this week.  also, in the future, please file jiras for
stuff like this rather than pinging me on the list.  ;)

On Wed, Jun 19, 2019 at 1:39 PM Xiao Li  wrote:

> That sounds good to me!
>
> @shane knapp   Could you help this? Or Dongjoon can
> do it by himself since he has the access?
>
> Cheers,
>
> Xiao
>
> On Wed, Jun 19, 2019 at 10:56 AM Dongjoon Hyun 
> wrote:
>
>> Hi, All.
>>
>> So far, we have only `hadoop-2.7` profile jobs.
>>
>> - SBT with hadoop-2.7
>> - Maven with hadoop-2.7 (on JDK8 and JDK11)
>>
>> Can we have a `Hadoop-3.2` profile Jenkins job for Spark 3.0.0?
>>
>> Bests,
>> Dongjoon.
>>
>
>
> --
> [image: Databricks Summit - Watch the talks]
> 
>


-- 
Shane Knapp
UC Berkeley EECS Research / RISELab Staff Technical Lead
https://rise.cs.berkeley.edu

Re: Jenkins Jobs for Hadoop-3.2 profile

[Xiao Li]

That sounds good to me!

@shane knapp   Could you help this? Or Dongjoon can do
it by himself since he has the access?

Cheers,

Xiao

On Wed, Jun 19, 2019 at 10:56 AM Dongjoon Hyun 
wrote:

> Hi, All.
>
> So far, we have only `hadoop-2.7` profile jobs.
>
> - SBT with hadoop-2.7
> - Maven with hadoop-2.7 (on JDK8 and JDK11)
>
> Can we have a `Hadoop-3.2` profile Jenkins job for Spark 3.0.0?
>
> Bests,
> Dongjoon.
>


-- 
[image: Databricks Summit - Watch the talks]

Re: Exposing JIRA issue types at GitHub PRs

[Dongjoon Hyun]

Thank you for feedback, Gengliang and Gabor!

Yes. The commit title and message is still important. There will be no
change for the existing PR title policy.
I've received AmpLab Jenkins permission yesterday. I'm looking at the infra.

Bests,
Dongjoon.


On Wed, Jun 19, 2019 at 2:46 AM Gabor Somogyi  wrote:

> 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  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 
>> wrote:
>>
>> Dongjoon, I think it's useful. Thanks for adding it!
>>
>> On Mon, Jun 17, 2019 at 8:05 AM Dongjoon Hyun 
>> wrote:
>>
>>> Thank you, Hyukjin !
>>>
>>> On Sun, Jun 16, 2019 at 4:12 PM Hyukjin Kwon 
>>> wrote:
>>>
 Labels look good and useful.

 On Sat, 15 Jun 2019, 02:36 Dongjoon Hyun, 
 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 
> 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 
>>> 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, 
 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.
>>
>
>>

Jenkins Jobs for Hadoop-3.2 profile

[Dongjoon Hyun]

Hi, All.

So far, we have only `hadoop-2.7` profile jobs.

- SBT with hadoop-2.7
- Maven with hadoop-2.7 (on JDK8 and JDK11)

Can we have a `Hadoop-3.2` profile Jenkins job for Spark 3.0.0?

Bests,
Dongjoon.

Re: Ask for ARM CI for spark

[Sean Owen]

I'd begin by reporting and fixing ARM-related issues in the build. If
they're small, of course we should do them. If it requires significant
modifications, we can discuss how much Spark can support ARM. I don't
think it's yet necessary for the Spark project to run these CI builds
until that point, but it's always welcome if people are testing that
separately.

On Wed, Jun 19, 2019 at 7:41 AM Holden Karau  wrote:
>
> Moving to dev@ for increased visibility among the developers.
>
> On Wed, Jun 19, 2019 at 1:24 AM Tianhua huang  
> wrote:
>>
>> Thanks for your reply.
>>
>> As I said before, I met some problem of build or test for spark on aarch64 
>> server, so it will be better to have the ARM CI to make sure the spark is 
>> compatible for AArch64 platforms.
>>
>> I’m from OpenLab team(https://openlabtesting.org/ ,a community to do open 
>> source project testing. And we can support some Arm virtual machines to 
>> AMPLab Jenkins, and also we have a developer team that willing to work on 
>> this, we willing to maintain build CI jobs and address the CI issues.  What 
>> do you think?
>>
>>
>> Thanks for your attention.
>>
>>
>> On Wed, Jun 19, 2019 at 6:39 AM shane knapp  wrote:
>>>
>>> yeah, we don't have any aarch64 systems for testing...  this has been asked 
>>> before but is currently pretty low on our priority list as we don't have 
>>> the hardware.
>>>
>>> sorry,
>>>
>>> shane
>>>
>>> On Mon, Jun 10, 2019 at 7:08 PM Tianhua huang  
>>> wrote:

 Hi, sorry to disturb you.
 The CI testing for apache spark is supported by AMPLab Jenkins, and I find 
 there are some computers(most of them are Linux (amd64) arch) for the CI 
 development, but seems there is no Aarch64 computer for spark CI testing. 
 Recently, I build and run test for spark(master and branch-2.4) on my arm 
 server, and unfortunately there are some problems, for example, ut test is 
 failed due to a LEVELDBJNI native package, the details for java test see 
 http://paste.openstack.org/show/752063/ and python test see 
 http://paste.openstack.org/show/752709/
 So I have a question about the ARM CI testing for spark, is there any plan 
 to support it? Thank you very much and I will wait for your reply!
>>>
>>>
>>>
>>> --
>>> Shane Knapp
>>> UC Berkeley EECS Research / RISELab Staff Technical Lead
>>> https://rise.cs.berkeley.edu
>
>
>
> --
> Twitter: https://twitter.com/holdenkarau
> Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9
> YouTube Live Streams: https://www.youtube.com/user/holdenkarau

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: Ask for ARM CI for spark

[Holden Karau]

Moving to dev@ for increased visibility among the developers.

On Wed, Jun 19, 2019 at 1:24 AM Tianhua huang 
wrote:

> Thanks for your reply.
>
> As I said before, I met some problem of build or test for spark on aarch64
> server, so it will be better to have the ARM CI to make sure the spark is 
> compatible
> for AArch64 platforms.
>
> I’m from OpenLab team(https://openlabtesting.org/ ,a community to do open
> source project testing. And we can support some Arm virtual machines to
> AMPLab Jenkins, and also we have a developer team that willing to work on
> this, we willing to maintain build CI jobs and address the CI issues.
> What do you think?
>
>
> Thanks for your attention.
>
> On Wed, Jun 19, 2019 at 6:39 AM shane knapp  wrote:
>
>> yeah, we don't have any aarch64 systems for testing...  this has been
>> asked before but is currently pretty low on our priority list as we don't
>> have the hardware.
>>
>> sorry,
>>
>> shane
>>
>> On Mon, Jun 10, 2019 at 7:08 PM Tianhua huang 
>> wrote:
>>
>>> Hi, sorry to disturb you.
>>> The CI testing for apache spark is supported by AMPLab Jenkins, and I
>>> find there are some computers(most of them are Linux (amd64) arch) for
>>> the CI development, but seems there is no Aarch64 computer for spark CI
>>> testing. Recently, I build and run test for spark(master and branch-2.4) on
>>> my arm server, and unfortunately there are some problems, for example, ut
>>> test is failed due to a LEVELDBJNI native package, the details for java
>>> test see http://paste.openstack.org/show/752063/ and python test see
>>> http://paste.openstack.org/show/752709/
>>> So I have a question about the ARM CI testing for spark, is there any
>>> plan to support it? Thank you very much and I will wait for your reply!
>>>
>>
>>
>> --
>> Shane Knapp
>> UC Berkeley EECS Research / RISELab Staff Technical Lead
>> https://rise.cs.berkeley.edu
>>
>

-- 
Twitter: https://twitter.com/holdenkarau
Books (Learning Spark, High Performance Spark, etc.):
https://amzn.to/2MaRAG9  
YouTube Live Streams: https://www.youtube.com/user/holdenkarau

Re: unsubscribe

[Swapnil M Mane]

Hello Tushar,
You need to help yourself to unsubscribe from the mailing list,
Please send a blank mail on dev-unsubscr...@spark.apache.org


- Best Regards,
Swapnil M Mane

On Wed, Jun 19, 2019 at 3:42 PM Tushar Marne  wrote:

>
>
> --
> Tushar Marne
> 9011062432
>

Re: usubscribe

[Swapnil M Mane]

Hello Игорь,
You need to help yourself to unsubscribe from the mailing list,
Please send a blank mail on dev-unsubscr...@spark.apache.org


- Best Regards,
Swapnil M Mane

On Wed, Jun 19, 2019 at 5:58 PM Игорь Самсонов 
wrote:

>
>

usubscribe

[Игорь Самсонов]

unsubscribe

[Tushar Marne]

-- 
Tushar Marne
9011062432

Re: Exposing JIRA issue types at GitHub PRs

[Gabor Somogyi]

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  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 
> wrote:
>
> Dongjoon, I think it's useful. Thanks for adding it!
>
> On Mon, Jun 17, 2019 at 8:05 AM Dongjoon Hyun 
> wrote:
>
>> Thank you, Hyukjin !
>>
>> On Sun, Jun 16, 2019 at 4:12 PM Hyukjin Kwon  wrote:
>>
>>> Labels look good and useful.
>>>
>>> On Sat, 15 Jun 2019, 02:36 Dongjoon Hyun, 
>>> 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 
 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 
>> 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,  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.
>

>

Re: Exposing JIRA issue types at GitHub PRs

[Gengliang Wang]

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  wrote:
> 
> Dongjoon, I think it's useful. Thanks for adding it!
> 
> On Mon, Jun 17, 2019 at 8:05 AM Dongjoon Hyun  > wrote:
> Thank you, Hyukjin !
> 
> On Sun, Jun 16, 2019 at 4:12 PM Hyukjin Kwon  > wrote:
> Labels look good and useful.
> 
> On Sat, 15 Jun 2019, 02:36 Dongjoon Hyun,  > 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  > 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  > 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  > 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,  > 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  > 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.