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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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! >>>>> >>>>
