I’ve been thinking about this for a while – time to do it for real.
For personal reasons, I need to withdraw from active SC contributions. I’ve been struggling for quite some time with conflicting demands on my time. In the SC community, this has manifested as a testy, even hostile, response from me to PR review comments. Brian has borne the brunt of that and deserves a specific apology.
I believe presently that, if I keep trying to contribute, it’s only a matter of time before I would lose my temper again. The SC community isn’t a laboratory for me to try to work out my problems. If I’m not sure that I can behave well, then it’s better for me to get out of the way, take care of demands closer to home, and let others manage the project without interference.
I have 8 open pull requests. I don’t wish to be responsible for them anymore. I think I should close them. What I’m not sure is – if they need to be finished, should someone else pull from my topic branch and continue with a new PR, or reopen the existing one?
In any case, here they are.
|EventStreamCleanup: Prevent double-firing of cleanup functions||Bug fix. Worth finishing.|
|lang: Fix system realtime message type codes||Bug fix. Seems not complicated.|
|Plugins: Integrator Ctor passes through the first sample only||Bug fix, but with possible API implications, which others would have to decide anyway.|
||Not critical, could just close it.|
|Classlib: ServerOptions: maxLogins may not exceed 32||Not critical, could just close it.|
|Test suite: Improve error handling in UnitTest||TBH I don’t remember what this one was about.|
|Topic/thread reschedule||New feature.|
|Classlib/Help: Raise maximum number of Buffer:getn/setn values||Probably just close this one and forget it, because some of it is platform-specific and not clear what the value should be.|
I will still be around – for one thing, I seem to be pretty good at finding and diagnosing bugs, and I think if I see some wrong behavior, I should be able to log issues for it. But I have to be able to control the amount of time investment, and that seems not to be possible with the way PRs are currently managed. So I’ll have to refrain from future PR authorship or reviewing.