And how to define practices and skills? If you guys do not have time to review the changes from contributors out of mono group, then how to find out new people to join the group? And, I continually see an incorrect design pattern in mono source code, which may cause unexpected behavior in multithreading environment. This kind of issue may not be able to get totally fixed, until someone else pointed out the design pattern is not correct.
.Hzj_jie ________________________________ From: Edward Ned Harvey (mono)<mailto:edward.harvey.m...@clevertrove.com> Sent: 21/9/2014 3:13 To: Miguel de Icaza<mailto:mig...@xamarin.com>; 何子杰Hzj_jie<mailto:hzj_...@hotmail.com> Cc: Steffen Kieß<mailto:steffen.ki...@ipvs.uni-stuttgart.de>; mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com> Subject: RE: [Mono-dev] System.Json string handling > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > Tru dat. However, I guess I'm actually trying to say two separate things: * When broken stuff doesn't get fixed, it's a disincentive for usage adoption. and * When pull requests get ignored, it is a disincentive to contributors trying to contribute anymore (fixing things). This is an unfortunate positive feedback loop, which can hopefully be broken some day. I know based on my experience here so far, I'm not going to bother trying to fix anything anymore. My time would have been better spent, finding an alternative to mono SslStream instead of trying to contribute the fix to make mono SslStream operational.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
