Very nice. There was an effort to get fast and green builds back in 2016.
There wasn't any strict "must be a green build" before commit at the time
though. Instead jiras were filed and the expectation was that they'd be
cited / new ones created pre commit(looking at the jiras now - this was
likely
Wow! Awesome. This is the 3rd time I remember seeing green run in >4yrs. :)
Thanks
Prasanth
> On May 15, 2018, at 5:28 PM, Jesus Camacho Rodriguez
> wrote:
>
> We have just had the first clean run in a while:
> https://builds.apache.org/job/PreCommit-HIVE-Build/10971/testReport/
>
> I will co
We have just had the first clean run in a while:
https://builds.apache.org/job/PreCommit-HIVE-Build/10971/testReport/
I will continue monitoring follow-up runs.
Thanks,
-Jesús
On 5/14/18, 11:28 PM, "Prasanth Jayachandran"
wrote:
Wondering if we can add a state transition from “Patch Ava
Wondering if we can add a state transition from “Patch Available” to “Ready To
Commit” which can only be triggered by ptest bot on green test run.
Thanks
Prasanth
On Mon, May 14, 2018 at 10:44 PM -0700, "Jesus Camacho Rodriguez"
mailto:jcama...@apache.org>> wrote:
I have been working on fix
I have been working on fixing this situation while commits were still coming in.
All the tests that have been disabled are in:
https://issues.apache.org/jira/browse/HIVE-19509
I have created new issues to reenable each of them, they are linked to that
issue.
Maybe I was slightly aggressive disabl
Can we please make this freeze conditional, i.e. we unfreeze automatically
after ptest is clean (as evidenced by the clean HiveQA run on a given
JIRA).
On 18/5/14, 15:16, "Alan Gates" wrote:
>We should do it in a separate thread so that people can see it with the
>[VOTE] subject. Some people us
We should do it in a separate thread so that people can see it with the
[VOTE] subject. Some people use that as a filter in their email to know
when to pay attention to things.
Alan.
On Mon, May 14, 2018 at 2:36 PM, Prasanth Jayachandran <
pjayachand...@hortonworks.com> wrote:
> Will there be a
Will there be a separate voting thread? Or the voting on this thread is
sufficient for lock down?
Thanks
Prasanth
> On May 14, 2018, at 2:34 PM, Alan Gates wrote:
>
> I see there's support for this, but people are still pouring in commits.
> I proposed we have a quick vote on this to lock dow
I see there's support for this, but people are still pouring in commits.
I proposed we have a quick vote on this to lock down the commits until we
get to green. That way everyone knows we have drawn the line at a specific
point. Any commits after that point would be reverted. There isn't a
cate
I worked on a few quick-fix optimizations in Ptest infrastructure over the
weekend which reduced the execution run from ~90 min to ~70 min per run. I
had to restart Ptest multiple times. I was resubmitting the patches which
were in the queue manually, but I may have missed a few. In case you have a
Vineet has already been working on disabling those tests that were timing out.
I am working on disabling those that are generating different q files
consistently for last ptests n runs. I am keeping track of all these tests in
https://issues.apache.org/jira/browse/HIVE-19509.
-Jesús
On 5/14/1
+1 on freezing commits until we get repetitive green tests. We should probably
disable (and remember in a jira to reenable then at later point) tests that are
flaky to get repetitive green test runs.
Thanks
Prasanth
On Mon, May 14, 2018 at 2:15 AM -0700, "Rui Li"
mailto:lirui.fu...@gmail.com
+1 to freezing commits until we stabilize
On Sat, May 12, 2018 at 6:10 AM, Vihang Karajgaonkar
wrote:
> In order to understand the end-to-end precommit flow I would like to get
> access to the PreCommit-HIVE-Build jenkins script. Does anyone one know how
> can I get that?
>
> On Fri, May 11, 201
In order to understand the end-to-end precommit flow I would like to get
access to the PreCommit-HIVE-Build jenkins script. Does anyone one know how
can I get that?
On Fri, May 11, 2018 at 2:03 PM, Jesus Camacho Rodriguez <
jcama...@apache.org> wrote:
> Bq. For the short term green runs, I think
Bq. For the short term green runs, I think we should @Ignore the tests which
are known to be failing since many runs. They are anyways not being
addressed as such. If people think they are important to be run we should
fix them and only then re-enable them.
I think that is a good idea, as we would
+1. I strongly vote for freezing commits and getting our testing coverage in
acceptable state. We have been struggling to stabilize branch-3 due to test
failures and releasing Hive 3.0 in current state would be unacceptable.
Currently there are quite a few test suites which are not even running
correction in my email below. I meant "in my opinion it *has now* become
number one bottleneck for the project" (worst place for a typo I guess)
On Fri, May 11, 2018 at 1:46 PM, Vihang Karajgaonkar
wrote:
> +1 There are many problems with the test infrastructure and in my opinion
> it has not be
+1 There are many problems with the test infrastructure and in my opinion
it has not become number one bottleneck for the project. I was looking at
the infrastructure yesterday and I think the current infrastructure (even
its own set of problems) is still under-utilized. I am planning to increase
t
I believe we have reached a state (maybe we did reach it a while ago) that is
not sustainable anymore, as there are so many tests failing / timing out that
it is not possible to verify whether a patch is breaking some critical parts of
the system or not. It also seems to me that due to the timeo
19 matches
Mail list logo