Given what you just said then I'd say 0+ and leaning in favour of not holding up the release and aiming for a shorter release cycle.
On Tue, Aug 25, 2020 at 8:50 AM Robbie Gemmell <[email protected]> wrote: > 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] > >
