You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2021/05/11 10:56:27 UTC

Re: [DISCUSS] code freeze 3.4.11/3.5.0

Branches are reopened. I've pushed a 3.5-dev branch so the merge pattern
now is 3.4-dev -> 3.5-dev -> master.

On Wed, Apr 28, 2021 at 3:16 PM Stephen Mallette <sp...@gmail.com>
wrote:

> sorry for all the JIRA noise - mostly just moving "assigned by" fields a
> bit. some stuff no one is really looking at right now, so just doing a bit
> of issue tracker hygiene. there's still a lot of old issues out there which
> could probably be closed, but they hold a few nice ideas that kinda haunt
> TP3 so i've left them alone as we've trucked along. anyway, might yet close
> a few issues as things we're not going to ever work on, so perhaps a few
> more emails may come through to dev yet.
>
> On Wed, Apr 28, 2021 at 2:56 PM Stephen Mallette <sp...@gmail.com>
> wrote:
>
>> I've published fresh SNAPSHOT artifacts and docs for review:
>>
>> https://tinkerpop.apache.org/docs/3.4.11-SNAPSHOT/
>> https://tinkerpop.apache.org/docs/3.5.0-SNAPSHOT/
>>
>> If you happen to have any time at all to review any of this, please spend
>> some time in the Upgrade Documentation for 3.5.0 as that will be the first
>> thing folks will be reading when we release:
>>
>> https://tinkerpop.apache.org/docs/3.5.0-SNAPSHOT/upgrade
>>
>>
>>
>> On Wed, Apr 28, 2021 at 9:10 AM Stephen Mallette <sp...@gmail.com>
>> wrote:
>>
>>> phew - it seems the slow down was related to the surefire plugin. i'd
>>> updated that on master to a newer version and it required some additional
>>> configuration options to run our stuff properly. once i reverted, to the
>>> same version as 3.4-dev the build speeds made more sense. i guess i'm going
>>> to keep it there for release. i imagine we'll revisit the upgrade in the
>>> future at some point.
>>>
>>> On Tue, Apr 27, 2021 at 3:41 PM Stephen Mallette <sp...@gmail.com>
>>> wrote:
>>>
>>>> I've been trying to sort out TINKERPOP-2550 with kerberos and recently
>>>> haven't been hassled by those sorts of errors in travis where they've been
>>>> occurring with some regularity. So that's good. I've also been testing and
>>>> re-testing around the deadlock issues I'd alluded to prior to code freeze.
>>>> Travis jobs seem much more stable on 3.4-dev, but since I've only just
>>>> started seeing master start to shape up the same way, I'd say I still need
>>>> to keep testing that branch.
>>>>
>>>> I'm also noticing that the build on master is almost twice as long as
>>>> 3.4-dev. I don't know why and I can't say with certainty when that started
>>>> to happen. My benchmarking effort didn't show a slow down with
>>>> driver/server operations so that finding is somewhat at odds with the build
>>>> itself. There are more tests on master but I didn't think there were
>>>> significantly more to make up for this difference. I'll be looking into
>>>> this issue further as well.
>>>>
>>>>
>>>> On Sat, Apr 24, 2021 at 5:47 AM Stephen Mallette <sp...@gmail.com>
>>>> wrote:
>>>>
>>>>> Another code freeze week and this time a big one for 3.5.0. All PRs of
>>>>> a blocking nature were merged so that's good. I'm still finding Travis a
>>>>> bit finicky with kerberos even after a fair bit of effort on
>>>>>
>>>>> https://issues.apache.org/jira/browse/TINKERPOP-2504
>>>>>
>>>>> but that's always been an issue so I'm not thinking that a blocker. I
>>>>> expect to close that issue and open a new one specific to kerberos unless.
>>>>> I'm still examining some issues with:
>>>>>
>>>>> https://issues.apache.org/jira/browse/TINKERPOP-2550
>>>>>
>>>>> despite it being closed. Found another interesting deadlock that can
>>>>> occur on close where a synchronized method was calling itself in low
>>>>> resource environments like travis. I'm going to watch travis for more hangs
>>>>> and run more tests this week.If you'd like to help test this, you can run
>>>>> the docker build with --cpus=0.9 (smart HadoopMarch idea there) or go to
>>>>> the TestClientFactory and set the workerPoolSize on the Cluster in the
>>>>> build() method to 1 and then run the build. Or alternatively, just write
>>>>> your own little tests with a Cluster you construct with that setting. I'd
>>>>> be happy to hear if anyone managed to do the latter actually and if they
>>>>> ran to some success or failure and what kind of test they wrote in the
>>>>> process. I think the problem at this point tend to generate from
>>>>> sessionless requests and open/close situations but any sort of testing is
>>>>> helpful.
>>>>>
>>>>> Other than that, let's focus on testing and documentation review this
>>>>> week and then head on to release. Thanks!
>>>>>
>>>>