I have no problem blocking on #589, so long as it remains actionable. We need to try to narrow down on the problem, and if possible reproduce it somewhere else.
Does this occur on any other cpan module? Would you mind trying to find out? Does it still happen in mobogdb in a fresh/new perlbrew if you spin one up? Until we find a way to reproduce this in a condition that is not "xdg's machine and module" would you mind running the tests with a handful of patches (1 at a time) if I get them to you asap? (to help me hone in on the problem) If we cannot find any other module or machine to reproduce the issue, and you are unable or unwilling to help debug then I will have an objection to blocking on this. -Chad On Thu, Apr 30, 2015 at 3:08 AM, David Golden <x...@xdg.me> wrote: > I consider this ticket a blocker: > https://github.com/Test-More/test-more/issues/589 > > I realize that it's hard to replicate and we may need to see if the > problem crops up elsewhere for confirmation, but sporadic global > destruction memory errors isn't something I want released to the world. > > David > > > On Thu, Apr 30, 2015 at 1:27 AM, Chad Granum <exodi...@gmail.com> wrote: > >> _110 uploaded as expected, documentation changes only. Unless someone >> else reports something that NEEDS to be fixed, nothing will be touched >> until stable. >> >> On Wed, Apr 29, 2015 at 9:52 AM, Chad Granum <exodi...@gmail.com> wrote: >> >>> I do not consider Test-Stream to be experimental. I am also unhappy with >>> the churn that has occurred, and recognize that it makes things hard for >>> people who are spot-checking me, specially since it means starting over. >>> >>> - Changes up to and including _105 were directly a result of the >>> punchlist and QAH review. >>> - Changes after _105 have to do with some concurrency things >>> discovered in peer review (See my other email). >>> - I consider the concurrency issue from _106->_109 fixed and done, >>> no more churn should be coming from that >>> - I have one more task on my todo list, a documentation audit, no >>> code change expected, just POD. >>> >>> I do not feel that either of these parts of churn should have been put >>> off. These were not the results of me playing around, or with >>> experimenting. These were things that review found that needed to be >>> addressed before a stable release locked them into stone. There are plenty >>> of other things in branches and pull requests (from bulk88, and some from >>> me) that I refuse to merge before a stable release is made because they >>> would introduce unnecessary churn. >>> >>> Now, about easing the burden of spot-checkers: >>> >>> I think that the spot-checkers choosing to wait until an entire week (7 >>> days) has gone by with no new dev releases, and no new commits to >>> stream/master before running their checks is perfectly reasonable. I tend >>> to address things within hours of finding out about them, so a week of no >>> churn is a really good measurement to go with. >>> >>> So, I hope to do my documentation audit today, and release _110 with >>> ONLY doc changes tonight. If there is no churn for 1 full week the spot >>> checkers can be sure I have nothing left to change and I consider it >>> release-ready, and they can do their spot checks. >>> >>> -Chad >>> >> >> > > > -- > David Golden <x...@xdg.me> Twitter/IRC: @xdg >
