0's typically still have a + or -, especially with all the text :) The threaderciser test appears to have a simple off switch, so that doesn't seem like a blocker. As noone can be using the 'raw connection' stuff fully yet, they also can't really be impacted by issues with it yet either. If there's something needing a fix it probably won't arrive any sooner by holding the release up to respin (vs doing another when potential change is available), so I dont see that as a true blocker currently either.
I'd happily do an RC2 if there were actually something critical ready to put in it or looking to come imminently, but right now that doesn't appear to be the case. It already took a lot of my time to this point, and it's essentially the same amount of work for me in order to do a respin as it is to do another actual release. We should really do more releases, so I'll generally tend toward releasing if there aren't true blockers, because it gets fixes/improvements that are ready out there. Currently the vote is passing (with 3 +1's, and a 0), and the release would proceed. I'm happy to be convinced otherwise, or for the vote tally itself to go another way should folks actually test it and/or want to vote negatively. Which is why the vote has remained open, longer than needed, to give folks more opportunity to provide such feedback (and/or changes that warrant an RC2). Robbie On Tue, 25 Aug 2020 at 11:15, Roddie Kieley <[email protected]> wrote: > > 0 > > To follow up on Chuck's testing I had originally observed the threaderciser > issue on macOS 10.14 in my first round of testing a few days ago when I ran > 4 sets of tests and all had only 1 failure - c_threaderciser. > In retesting this morning on the same platform with the same build with no > reboots or anything in between all tests pass including c_threaderciser, so > I can confirm the intermittent nature of the failure as noted in > PROTON-2259 [1]. > > In testing the new examples, raw_echo and raw_connect I saw that raw_echo > worked ok but raw_connect consistently reported: > > i7mbp:examples rkieley$ ./raw_connect > Segmentation fault: 11 > i7mbp:examples rkieley$ > > While the regular broker/receive/send, broker/simple_recv/simple_send and > others all operated as expected. > > I think perhaps an rc2 is warranted, however haven't had a chance to > identify earlier and help address the following: > - the raw connection work is a big feature addition and may just require a > small update > - the threaderciser work via PROTON-2225 had ' Set -DTHREADERCISER=ON by > default, to prevent regressions' [1] so it seems fair to expect that it > would help reduce problems. > > As such I don't feel strongly enough to -1 > > > Roddie > --- > [1] - https://issues.apache.org/jira/browse/PROTON-2259 > [2] - https://issues.apache.org/jira/browse/PROTON-2225 > > On Fri, Aug 21, 2020 at 11:40 AM Chuck Rolke <[email protected]> wrote: > > > Change to +1 > > > > Chalking up test failures to be a "test problem" and not a "proton > > problem". > > > > Local test setup first system, the one where the test fails: > > > > * ThinkPad P50 laptop > > * Linux unused.localdomain 5.7.9-100.fc31.x86_64 #1 SMP Fri Jul 17 > > 17:18:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > > > * Testbed ran overnight - no issues > > * c_threaderciser standalone C executable from command prompt: > > runs hundreds of times - no issues > > * c_threaderciser under ctest with valgrind-3.16.0, memcheck, leak check: > > passes sometimes but usually times out > > > > Local test setup second system: > > > > * Dell Inspiron desktop > > * Linux taj.localdomain 5.7.11-100.fc31.x86_64 #1 SMP Wed Jul 29 18:17:53 > > UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > > > * c_threaderciser under ctest with valgrind-3.16.0 passes every time > > ctest reporting elapsed time around 3 seconds, > > > > Problem system 'unused' has a significant difference from other systems > > with an > > NVIDIA Quadro M1000M GPU running NVIDIA Driver 450.57. > > > > > > ----- Original Message ----- > > > From: "Robbie Gemmell" <[email protected]> > > > To: [email protected] > > > Sent: Thursday, August 20, 2020 5:57:18 PM > > > Subject: Re: [VOTE] Release Apache Qpid Proton 0.32.0 > > > > > > On Thu, 20 Aug 2020 at 20:25, Andrew Stitcher <[email protected]> > > wrote: > > > > > > > > On Thu, 2020-08-20 at 14:50 -0400, Chuck Rolke wrote: > > > > > -1 > > > > > > > > > > * checksum matches > > > > > * built debug build > > > > > * threaderciser self test fails hard with timeout > > > > > > > > > > Issues with the test: > > > > > > > > > > - test does not honor ctest --timeout switch. Test always uses 120 > > > > > seconds. > > > > > - test times out with Debug, RelWithDebInfo, and Release builds > > > > > > > > > > Investigating a little: > > > > > - Sometimes takes 30 seconds just to *start* 8 threads > > > > > - Test times out with millisleep commented out. > > > > > -- sometimes with no user threads returning from join > > > > > -- sometimes user threads join but proactor threads do not > > > > > > > > Why would this be a reason to block the release if the bug that reports > > > > this behaviour [1] was not a blocker 3 months ago? > > > > > > > > Andrew > > > > > > > > [1] https://issues.apache.org/jira/browse/PROTON-2230 > > > > > > > > > > To be clear: a -1 on a release vote is not a block, they can't be > > > vetoed. If there are sufficient binding +1's and a net positive vote, > > > it is the release managers choice how to proceed based on issues > > > presented. So please keep testing and voting folks. > > > > > > In this case I'll essentially rely on those who would be fixing any > > > such issues to creating an argument/option not to proceed. If there > > > are no imminent changes/fix, and there doesn't seem to have been a new > > > change in behaviour from months ago, then so long as the vote tally > > > allows the release is currently likely to proceed. > > > > > > Chuck says it fails every time for him, which is interesting as it > > > hasn't done so elsewhere that I'm aware. Especially in a multitude of > > > builds/envs run over the last week that I have been looking to > > > progress with the release. That might make Chucks env useful for > > > nailing down any changes here. > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Robbie Gemmell" <[email protected]> > > > > > > To: [email protected] > > > > > > Sent: Thursday, August 20, 2020 6:29:22 AM > > > > > > Subject: [VOTE] Release Apache Qpid Proton 0.32.0 > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > I have put together a spin for a Qpid Proton 0.32.0 release, please > > > > > > give it a test out and vote accordingly. > > > > > > > > > > > > The files can be grabbed from: > > > > > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.32.0-rc1/ > > > > > > > > > > > > The JIRAs assigned are: > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720&version=12348172 > > > > > > > > > > > > It is tagged as 0.32.0-rc1. > > > > > > > > > > > > Regards, > > > > > > Robbie > > > > > > > > > > > > ----------------------------------------------------------------- > > > > > > ---- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
