Today if you add a link to a PR on the main repo to a JIRA ticket and put
it in patch available status, yetus should properly recognize and use it
for testing. The results should go to JIRA like normal.
I don't think it's gotten much testing in our setup. (And it wouldn't work
on the operator
Hurm. No obvious why this failed. It reports a ton of bad links, but all of
the successful runs before also report a ton of them if you look at the
console output.
On Fri, Dec 7, 2018, 23:25 Apache Jenkins Server Failure
>
> Either the Jenkins job failed, or (more likely) HTML errors were found.
This issue is with the content of index.html file. check-website-links.sh
script checks for ERROR in the generated index.html and at this time the
content of this html is empty.
I think this is the root cause:
Checking /0.94/apidocs/src-html/org/apache/hadoop/hbase/thrift/generate ...
Warning:
Peter Somogyi created HBASE-21569:
-
Summary: Incorrect validation in check-website-links.sh
Key: HBASE-21569
URL: https://issues.apache.org/jira/browse/HBASE-21569
Project: HBase
Issue Type:
On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote:
> The move to gitbox doesn't require us to only accept github PRs. Given
> the current rate of contributions via patches on JIRA vs GitHub PRs, I
> wouldn't want to push for that now.
>
> The change does make it easier for us to start encouraging
On Fri, Dec 7, 2018 at 5:59 PM Andrew Purtell wrote:
> We could do that. Or we could simply renumber branch-1 to 1.6.x at that
> time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a tag
> in rel/. It is possible at any time to check out from a release tag and
> make a branch
Sounds good to me except squash merge at commit of PR shouldn’t be an option it
should be required except for good reason (and I don’t know what that would be
)
> On Dec 8, 2018, at 3:28 PM, Stack wrote:
>
>> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey wrote:
>>
>> The move to gitbox
I think Andrew's way makes sense for branch-1, we can release 1.6,1.7 and
so on directly on branch-1. Since in branch-1, we will only have bug fixes.
If we want to apply this policy to branch-2, we'd be careful when new
functions check in, because all feature releases will include this function
if
+1, the less, the better.
Best Regards
Allan Yang
Sean Busbey 于2018年12月8日周六 上午10:09写道：
> correct, branch-1.2 was the stable release line prior to 1.4 becoming
> it in August.
>
> at the time I said I'd keep making monthly 1.2.z releases for ~6 months:
>
> https://s.apache.org/EYkB
>
> I wanted
