Re: Jenkins automatic disabling service - who and why?
I'm not sure if anything changed. What is the particular issue here? Looks like for some reason Jenkins first asked for admin approval well after the discussion started. Nobody asked for a test after that. Can you not trigger it from the web app UI? On Mon, Sep 3, 2018, 1:54 AM Hyukjin Kwon wrote: > Hi all, > > I lately noticed we started to block Jenkins tests in old PRs. For > instance, see https://github.com/apache/spark/pull/18447 > I don't explicitly object this idea but at least can I ask who and why > this was started? > Is it for notification purpose or to save resource? Did I miss some > discussion about this? > >
Re: Jenkins automatic disabling service - who and why?
Not a big deal but it has been few months since I saw this, and wondering why it suddenly asks Jenkins admin verification from at certain point. I had a small argument about pinging stuff related with this and I failed to give the reasons. So I was simply wondering why and who. On Mon, 3 Sep 2018, 8:04 pm Sean Owen, wrote: > I'm not sure if anything changed. What is the particular issue here? Looks > like for some reason Jenkins first asked for admin approval well after the > discussion started. Nobody asked for a test after that. Can you not trigger > it from the web app UI? > > On Mon, Sep 3, 2018, 1:54 AM Hyukjin Kwon wrote: > >> Hi all, >> >> I lately noticed we started to block Jenkins tests in old PRs. For >> instance, see https://github.com/apache/spark/pull/18447 >> I don't explicitly object this idea but at least can I ask who and why >> this was started? >> Is it for notification purpose or to save resource? Did I miss some >> discussion about this? >> >>
Re: Jenkins automatic disabling service - who and why?
> Looks like for some reason Jenkins first asked for admin approval well after the discussion started. Oh, for the specific PR, Felix approved a Jenkins test. Jenkins asked this before. Somehow after few weeks(?), Jenkins asked it again. It happened globally in multiple PRs. It's not shown because when we type "ok to test", the Jenkins asking is gone away. 2018년 9월 3일 (월) 오후 8:54, Hyukjin Kwon 님이 작성: > Not a big deal but it has been few months since I saw this, and wondering > why it suddenly asks Jenkins admin verification from at certain point. > > I had a small argument about pinging stuff related with this and I failed > to give the reasons. So I was simply wondering why and who. > > > > On Mon, 3 Sep 2018, 8:04 pm Sean Owen, wrote: > >> I'm not sure if anything changed. What is the particular issue here? >> Looks like for some reason Jenkins first asked for admin approval well >> after the discussion started. Nobody asked for a test after that. Can you >> not trigger it from the web app UI? >> >> On Mon, Sep 3, 2018, 1:54 AM Hyukjin Kwon wrote: >> >>> Hi all, >>> >>> I lately noticed we started to block Jenkins tests in old PRs. For >>> instance, see https://github.com/apache/spark/pull/18447 >>> I don't explicitly object this idea but at least can I ask who and why >>> this was started? >>> Is it for notification purpose or to save resource? Did I miss some >>> discussion about this? >>> >>>
Re: Jenkins automatic disabling service - who and why?
I think Jenkins asked again after there was an upgrade - seems to happen when the PR was opened for a few months. From: Hyukjin Kwon Sent: Monday, September 3, 2018 7:05 AM To: Sean Owen Cc: dev Subject: Re: Jenkins automatic disabling service - who and why? > Looks like for some reason Jenkins first asked for admin approval well after > the discussion started. Oh, for the specific PR, Felix approved a Jenkins test. Jenkins asked this before. Somehow after few weeks(?), Jenkins asked it again. It happened globally in multiple PRs. It's not shown because when we type "ok to test", the Jenkins asking is gone away. 2018년 9월 3일 (월) 오후 8:54, Hyukjin Kwon mailto:gurwls...@gmail.com>>님이 작성: Not a big deal but it has been few months since I saw this, and wondering why it suddenly asks Jenkins admin verification from at certain point. I had a small argument about pinging stuff related with this and I failed to give the reasons. So I was simply wondering why and who. On Mon, 3 Sep 2018, 8:04 pm Sean Owen, mailto:sro...@gmail.com>> wrote: I'm not sure if anything changed. What is the particular issue here? Looks like for some reason Jenkins first asked for admin approval well after the discussion started. Nobody asked for a test after that. Can you not trigger it from the web app UI? On Mon, Sep 3, 2018, 1:54 AM Hyukjin Kwon mailto:gurwls...@gmail.com>> wrote: Hi all, I lately noticed we started to block Jenkins tests in old PRs. For instance, see https://github.com/apache/spark/pull/18447 I don't explicitly object this idea but at least can I ask who and why this was started? Is it for notification purpose or to save resource? Did I miss some discussion about this?
Re: Spark JIRA tags clarification and management
+1 good idea. There are a few for organizing but some also are critical to the release process, like rel note. Would be good to clarify. From: Reynold Xin Sent: Sunday, September 2, 2018 11:50 PM To: Hyukjin Kwon Cc: dev Subject: Re: Spark JIRA tags clarification and management It would be great to document the common ones. On Sun, Sep 2, 2018 at 11:49 PM Hyukjin Kwon mailto:gurwls...@gmail.com>> wrote: Hi all, I lately noticed tags are often used to classify JIRAs. I was thinking we better explicitly document what tags are used and explain which tag means what. For instance, we documented "Contributing to JIRA Maintenance" at https://spark.apache.org/contributing.html before (thanks, Sean Owen) - this helps me a lot to managing JIRAs, and they are good standards for, at least, me to take an action. It doesn't necessarily mean we should clarify everything but it might be good to document tags used often. We can leave this for committer's scope as well, if that's preferred - I don't have a strong opinion on this. My point is, can we clarify this in the contributing guide so that we can reduce the maintenance cost?
Re: Spark JIRA tags clarification and management
Thanks, Felix and Reynold. Would you guys mind if I ask this to anyone who use the tags frequently? Frankly, I don't use the tags often .. 2018년 9월 4일 (화) 오전 2:04, Felix Cheung 님이 작성: > +1 good idea. > There are a few for organizing but some also are critical to the release > process, like rel note. Would be good to clarify. > > -- > *From:* Reynold Xin > *Sent:* Sunday, September 2, 2018 11:50 PM > *To:* Hyukjin Kwon > *Cc:* dev > *Subject:* Re: Spark JIRA tags clarification and management > > It would be great to document the common ones. > > On Sun, Sep 2, 2018 at 11:49 PM Hyukjin Kwon wrote: > >> Hi all, >> >> I lately noticed tags are often used to classify JIRAs. I was thinking we >> better explicitly document what tags are used and explain which tag means >> what. For instance, we documented "Contributing to JIRA Maintenance" at >> https://spark.apache.org/contributing.html before (thanks, Sean Owen) - >> this helps me a lot to managing JIRAs, and they are good standards for, at >> least, me to take an action. >> >> It doesn't necessarily mean we should clarify everything but it might be >> good to document tags used often. >> >> We can leave this for committer's scope as well, if that's preferred - I >> don't have a strong opinion on this. My point is, can we clarify this in >> the contributing guide so that we can reduce the maintenance cost? >> >>
Re: Spark JIRA tags clarification and management
The most common ones we do are: releasenotes correctness On Mon, Sep 3, 2018 at 6:23 PM Hyukjin Kwon wrote: > Thanks, Felix and Reynold. Would you guys mind if I ask this to anyone who > use the tags frequently? Frankly, I don't use the tags often .. > > 2018년 9월 4일 (화) 오전 2:04, Felix Cheung 님이 작성: > >> +1 good idea. >> There are a few for organizing but some also are critical to the release >> process, like rel note. Would be good to clarify. >> >> -- >> *From:* Reynold Xin >> *Sent:* Sunday, September 2, 2018 11:50 PM >> *To:* Hyukjin Kwon >> *Cc:* dev >> *Subject:* Re: Spark JIRA tags clarification and management >> >> It would be great to document the common ones. >> >> On Sun, Sep 2, 2018 at 11:49 PM Hyukjin Kwon wrote: >> >>> Hi all, >>> >>> I lately noticed tags are often used to classify JIRAs. I was thinking >>> we better explicitly document what tags are used and explain which tag >>> means what. For instance, we documented "Contributing to JIRA Maintenance" >>> at https://spark.apache.org/contributing.html before (thanks, Sean >>> Owen) - this helps me a lot to managing JIRAs, and they are good standards >>> for, at least, me to take an action. >>> >>> It doesn't necessarily mean we should clarify everything but it might be >>> good to document tags used often. >>> >>> We can leave this for committer's scope as well, if that's preferred - I >>> don't have a strong opinion on this. My point is, can we clarify this in >>> the contributing guide so that we can reduce the maintenance cost? >>> >>>
Re: Spark JIRA tags clarification and management
Thanks, Reynold. +Adding Xiao and Wenchen who I saw often used tags. Would you have some tags you think we should document more? 2018년 9월 4일 (화) 오전 9:27, Reynold Xin 님이 작성: > The most common ones we do are: > > releasenotes > > correctness > > > > On Mon, Sep 3, 2018 at 6:23 PM Hyukjin Kwon wrote: > >> Thanks, Felix and Reynold. Would you guys mind if I ask this to anyone >> who use the tags frequently? Frankly, I don't use the tags often .. >> >> 2018년 9월 4일 (화) 오전 2:04, Felix Cheung 님이 작성: >> >>> +1 good idea. >>> There are a few for organizing but some also are critical to the release >>> process, like rel note. Would be good to clarify. >>> >>> -- >>> *From:* Reynold Xin >>> *Sent:* Sunday, September 2, 2018 11:50 PM >>> *To:* Hyukjin Kwon >>> *Cc:* dev >>> *Subject:* Re: Spark JIRA tags clarification and management >>> >>> It would be great to document the common ones. >>> >>> On Sun, Sep 2, 2018 at 11:49 PM Hyukjin Kwon >>> wrote: >>> Hi all, I lately noticed tags are often used to classify JIRAs. I was thinking we better explicitly document what tags are used and explain which tag means what. For instance, we documented "Contributing to JIRA Maintenance" at https://spark.apache.org/contributing.html before (thanks, Sean Owen) - this helps me a lot to managing JIRAs, and they are good standards for, at least, me to take an action. It doesn't necessarily mean we should clarify everything but it might be good to document tags used often. We can leave this for committer's scope as well, if that's preferred - I don't have a strong opinion on this. My point is, can we clarify this in the contributing guide so that we can reduce the maintenance cost?
