> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > Getting reviewed is one thing. (Difficult enough.) Getting approved is a > completely different thing - even more perilous. > > ... etc etc yadda yadda ...
Actually, I'm frustrated with MYSELF over this message, and thinking some more about what message the message sends. As I said, I try to restrain myself and letting my jadedness come through. But I obviously failed and let it through in that message. (I'm choking and swallowing my pride and apologizing for not being more productive.) As David said, I love .Net and C# and I invest time (me too) advocating it to colleagues and peers, but some parts (like my own email a moment ago) give me pause and make me hesitate and reflect. So here's the deal. Mono is huge and complex, and awesome too. We don't have somebody the size of Microsoft supporting it. If you go to mono-project.com and try to figure out, "How can I get support for mono" I forget exactly what you see, but it effectively says try the community, and consider paying Xamarin. So we work with the community to encounter roadblocks and we pay Xamarin and still get no support for mono. This is both a barrier to advocacy, and also a barrier to businesses who want to stake their business core on mono. As a consistent advocate for mono and Xamarin over the last 2-3 years, I am constantly questioned by peers and constantly question myself, whether or not I regret my decisions to base my company on mono and Xamarin. The question is still up in the air, but I weakly think I still agree with myself. I know it costs money to support & develop mono. I know none of the answers are easy. Miguel, this is probably a question for you. (And by the way, thank you for everything, and especially thank you for participating here.) I don't want to use the linux kernel development cycle as the model we should be following, but I do want to point out one thing: They do indeed take lots and lots of contributions from hugely varied groups of diverse and disperse individuals. Here, my patch that got rejected, said it would break some other class or something that I never heard of before. If that's true, it would only seem natural, that if I had run unit tests after making my patch, I would have discovered that before submitting the pull request. Likewise, the bottleneck that's preventing much community contribution is *primarily* the fear of community contributions breaking other things. My case is the poster child. So this sounds like an area that is actually *feasible* to really make a huge improvement on: Can we please, formally adopt a process that community contributors can follow, and reasonably expect (a) that their contributions won't break anything, and (b) that their contributions will consequently be reviewed in a reasonable timeframe? One thing in particular that's missing is a formal definition of how the community contributors should run unit tests. It doesn't necessarily need to be easy - As we all know, mono is a huge complex and awesome project. If it's absolutely necessary to run unit tests on 7 versions of linux, OSX, android and iOS, then so be it. While none of us are prepared to run those kinds of tests right now, you put the target up in the air and tell the community "Figure out some way community contributors can regularly and habitually run these tests before submitting code" and we'll be energized as a result of having a clear *direction* and I'm certain we'll find a way to hit that target. I know there's lots of work on the platter, but this in particular is something I think you can afford to do, with huge implications of community good will, and long-term growth and adoption. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
