Thanks all for the quick responses!
I'm not sure what all integration there is with GH directly. I know
Yetus is smart enough to find PR's when they end in .patch when
commented on a JIRA issue (e.g.
https://github.com/apache/accumulo/pull/63.patch).
I would guess that attachments are only looked at if they end in .diff
or .patch. I'm not sure how the "Patch Available" status affects things
(I know it was important for the old HadoopQA jobs which eventually
evolved into Yetus).
Somehow, I already had the appropriate karma to read/modify Jenkins. I
job I made was cloned from the HBase one. I would guess this is an infra
ask? I am not entirely sure how I got the karma in the first place. I am
also not sure if there are other levels which protect our job from
others changing the configuration (as I have the ability to go and
modify any), but I'm not super concerned about this.
Christopher wrote:
On by default: +1
Separate JIRA account: makes sense
Concerns about -1/+1 in CTR: it's informs the committers, but isn't
binding, so I'm not concerned
Questions:
Is this just for PRs or patches, too? If patches also, how do we identify
patches vs. other JIRA attachments?
How do other committers/PMC tweak/modify the settings? Are permissions
similar to Jenkins at builds.apache.org?
On Fri, Jan 8, 2016 at 1:41 PM John Vines<[email protected]> wrote:
+1
On Fri, Jan 8, 2016 at 12:58 PM Keith Turner<[email protected]> wrote:
+1
On Fri, Jan 8, 2016 at 12:24 PM, Josh Elser<[email protected]>
wrote:
Hi,
Per the other thread "Yetus Accumulo 'Personality'" [1], I'd like to
see
what people think about turning this on by default.
I've been talking to Sean in chat today who had made a suggestion that
we
get our own JIRA acct instead of the "Hadoop QA" user. Aside from that,
I'm
pretty happy with this.
There is likely further tweaking we can do (e.g. multijdk builds, try
the
sunny-day ITs). One big concern is the presence of a -1/+1 in an CTR
community. We would need some docs to be clear that the PreCommit
comment
is a tool for vetting contributions, not a bar that must be satisfied
prior
to commit (this is a simple website update).
Anywho -- if you have opinions, please let them be heard now. If there
isn't any argument against, I'll move ahead with this in time.
[1]
http://mail-archives.apache.org/mod_mbox/accumulo-dev/201601.mbox/%[email protected]%3E
