Re: [Mono-dev] Pull Requests
On 17/10/14 03:52, David Nelson wrote: ...my observations have not convinced me that such contributions would be an effective use of my time. Did your observations include only unmerged pull requests, or did you also happen to check how many of them get merged? The latter is important too. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Martin Thwaites Just to give my2cents on this. I would just like to know that things will get looked at approved at some point. Getting reviewed is one thing. (Difficult enough.) Getting approved is a completely different thing - even more perilous. Here's my example: Mono SslStream, when used as a server, is simply incompatible with mono SslStream when used as a client. Mono clients can talk to windows servers, and windows servers can talk to mono clients, and windows clients can talk to windows servers. The only incompatibility is Mono server Mono client. There was a bug report. It was marked as fixed, and closed, even though it wasn't fixed (obviously nobody tested, or didn't care that the test failed or something). I dug into it, patched it, submitted pull request, and we are now shipping product that requires customers to install our customized version of mono. We are paying Xamarin customers. For months, I tried to get attention amongst mono developers to review the pull request, and then - After I finally made enough noise, what happened was this: Patch was reviewed and rejected. Period. No discussion, no attempt to create a new fix, no nothing. It was the effective equivalent of telling me to shut up and go away. (That happened like 3 weeks ago or so). I am obviously left feeling extremely jaded. I know for damn sure I'm not going to bother submitting any patches any time soon, and I have to restrain myself every time I hear other people on this list thinking they're going to submit patches or help improve mono. Cuz I don't want to be the guy who just bitches and complains all the time. I remain hopeful this can change someday, but I'm pretty badly burned at the moment. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
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
[Mono-dev] Pull Requests
This topic has been brought up in a ton of other threads I just want to centralize the topic. I have felt the pain many others have discussed (6-12 months for an accept of PR, we actually had a separate distribution of mono for a while). Is there background on the issue? What are the issues that are involved from a xamarin perspective? How can the community help? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
Hello Greg, The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss. Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large. To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches. We have very nice fixes that we still postpone until we have the bandwidth of doing a full review. In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. Miguel On Thu, Oct 16, 2014 at 3:27 PM, Greg Young gregoryyou...@gmail.com wrote: This topic has been brought up in a ton of other threads I just want to centralize the topic. I have felt the pain many others have discussed (6-12 months for an accept of PR, we actually had a separate distribution of mono for a while). Is there background on the issue? What are the issues that are involved from a xamarin perspective? How can the community help? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
Miguel, In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. To be fair you know the pain we deal with due to this. For us if we had a backlog of 200 PRs this would be a wonderful problem to have. I would immediately hire 1-2 people to knock it down. I think what most people in the community perceive (which is why I started the topic) is that outside support is not making it into the pipeline. Cheers, Greg ps Miguel did I mention you need to come to Lithuania next year? On Thu, Oct 16, 2014 at 8:31 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss. Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large. To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches. We have very nice fixes that we still postpone until we have the bandwidth of doing a full review. In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. Miguel On Thu, Oct 16, 2014 at 3:27 PM, Greg Young gregoryyou...@gmail.com wrote: This topic has been brought up in a ton of other threads I just want to centralize the topic. I have felt the pain many others have discussed (6-12 months for an accept of PR, we actually had a separate distribution of mono for a while). Is there background on the issue? What are the issues that are involved from a xamarin perspective? How can the community help? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
Just to give my2cents on this. I would just like to know that things will get looked at approved at some point. I saw a while back that there was a flurry of activity on PR's, and some people (possibly after direction from Miguel) whacked that list down considerably. Is there anything that Xamarin can do to maybe help out with an ETA on reviewing pull requests? even if it's something along the lines of This needs X to review it, and we expect to get time next month. I know Xamarin staff aren't the only people who can approve, but maybe that's a fallback if noone can review it earlier. As always, love what you do, and as you said the bar is high in mono which I love. I'm actually using the mono codebase as an example for my staff to look at to see how an opensource project can be done right. Thanks, Martin On 16 October 2014 20:39, Greg Young gregoryyou...@gmail.com wrote: Miguel, In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. To be fair you know the pain we deal with due to this. For us if we had a backlog of 200 PRs this would be a wonderful problem to have. I would immediately hire 1-2 people to knock it down. I think what most people in the community perceive (which is why I started the topic) is that outside support is not making it into the pipeline. Cheers, Greg ps Miguel did I mention you need to come to Lithuania next year? On Thu, Oct 16, 2014 at 8:31 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss. Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large. To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches. We have very nice fixes that we still postpone until we have the bandwidth of doing a full review. In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. Miguel On Thu, Oct 16, 2014 at 3:27 PM, Greg Young gregoryyou...@gmail.com wrote: This topic has been brought up in a ton of other threads I just want to centralize the topic. I have felt the pain many others have discussed (6-12 months for an accept of PR, we actually had a separate distribution of mono for a while). Is there background on the issue? What are the issues that are involved from a xamarin perspective? How can the community help? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. This seems to be a chicken-and-egg problem. We need to christen more reviewers in order to handle the volume of PRs and keep the Mono community engaged; but in order to gain enough confidence in a contributor to make them a reviewer, their requests need to be reviewed! How can we develop the skills in the community if requests routinely sit idle for over a year? I got really excited about contributing to Mono about two years ago; I love .NET and C#, but many of my colleagues (not to mention many of the companies for which we consult) are staunchly anti-Windows; I wanted to help demonstrate that Mono could be a viable alternative for non-Windows development. But research into the state of the community left me disappointed: PRs are ignored, roadmaps are horribly out of date, builds are constantly broken...in general, not an environment that encourages community members to contribute their valuable time. I understand the desire to maintain a high standard for contributed code, and I support maintaining that standard; but a process MUST be developed that encourages community contribution rather than stagnating it. On Thu, Oct 16, 2014 at 3:31 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss. Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large. To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches. We have very nice fixes that we still postpone until we have the bandwidth of doing a full review. In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. Miguel On Thu, Oct 16, 2014 at 3:27 PM, Greg Young gregoryyou...@gmail.com wrote: This topic has been brought up in a ton of other threads I just want to centralize the topic. I have felt the pain many others have discussed (6-12 months for an accept of PR, we actually had a separate distribution of mono for a while). Is there background on the issue? What are the issues that are involved from a xamarin perspective? How can the community help? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
There is no point in starting a discussion where you are going to cherry pick facts for the sake of your argument. As for contributing, which one of *your* pull requests have been pending and not being reviewed? Because we would like to provide you with the valuable feedback that you need to turn these contributions into patches. Miguel On Thu, Oct 16, 2014 at 4:25 PM, David Nelson eatdrinksleepc...@gmail.com wrote: Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. This seems to be a chicken-and-egg problem. We need to christen more reviewers in order to handle the volume of PRs and keep the Mono community engaged; but in order to gain enough confidence in a contributor to make them a reviewer, their requests need to be reviewed! How can we develop the skills in the community if requests routinely sit idle for over a year? I got really excited about contributing to Mono about two years ago; I love .NET and C#, but many of my colleagues (not to mention many of the companies for which we consult) are staunchly anti-Windows; I wanted to help demonstrate that Mono could be a viable alternative for non-Windows development. But research into the state of the community left me disappointed: PRs are ignored, roadmaps are horribly out of date, builds are constantly broken...in general, not an environment that encourages community members to contribute their valuable time. I understand the desire to maintain a high standard for contributed code, and I support maintaining that standard; but a process MUST be developed that encourages community contribution rather than stagnating it. On Thu, Oct 16, 2014 at 3:31 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss. Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large. To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches. We have very nice fixes that we still postpone until we have the bandwidth of doing a full review. In the meantime, if you need quick hacks, you can always fork Mono and distribute your forked version with your changes. Miguel On Thu, Oct 16, 2014 at 3:27 PM, Greg Young gregoryyou...@gmail.com wrote: This topic has been brought up in a ton of other threads I just want to centralize the topic. I have felt the pain many others have discussed (6-12 months for an accept of PR, we actually had a separate distribution of mono for a while). Is there background on the issue? What are the issues that are involved from a xamarin perspective? How can the community help? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
Let me add a couple of points. First, I have noticed is that: - Contributors do not make a habit out of checking pull requests; I know I don't - GitHub is too chatty, so everyone I know just filters notifications. I suspect this is why anyone being assigned issues just ignores them. There is just too much traffic. Mono historically took patches from the mailing list. Not from github pull requests. So culturally, this was never aligned, it just kind of happened, and we kind of never evolved or changed with it. Perhaps what we need is for these pull requests to be posted here on the list and discussed here on the list. I think this is better, as we have a place where the larger community can comment on patches. It would surface the discussion to everyone, as opposed to limiting it to those that happen to stumble on the pull requests or visit the page. Second, I think there is a room for folks to contribute to this process, even if they are not committers, or active contributors. Someone that could shepherd a contributor and the contribution. Many of the patches do not meet the basic requirements for a patch review, and we end up wasting valuable time on them. Things that we would need: - An actual detailed explanation of the change. Many patches are submitted with very little information. - Test cases: many patches are contributed without tests to show the problem as it is today nor to ensure that the code does not regress. - Style: many patches contain white space changes, unnecessary refactoring and changes that are not suitable to be contributed. - Rebasing: many patches are contributed and fixes are piled on top of each other. The result is not suitable to be merged as it would essentially pollute the commit history. So someone that can assist the less sophisticated among us to squash the commits would help. - Patches that change the surface and contain no documentation. - Steering developers to discuss the patches on the mailing list and following up directly on the mailing list with the reviewers to ensure that the patches can be merged. I think the above would help us tremendously to accelerate the patch review process. Miguel On Thu, Oct 16, 2014 at 4:30 PM, Miguel de Icaza mig...@xamarin.com wrote: There is no point in starting a discussion where you are going to cherry pick facts for the sake of your argument. As for contributing, which one of *your* pull requests have been pending and not being reviewed? Because we would like to provide you with the valuable feedback that you need to turn these contributions into patches. Miguel On Thu, Oct 16, 2014 at 4:25 PM, David Nelson eatdrinksleepc...@gmail.com wrote: Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. This seems to be a chicken-and-egg problem. We need to christen more reviewers in order to handle the volume of PRs and keep the Mono community engaged; but in order to gain enough confidence in a contributor to make them a reviewer, their requests need to be reviewed! How can we develop the skills in the community if requests routinely sit idle for over a year? I got really excited about contributing to Mono about two years ago; I love .NET and C#, but many of my colleagues (not to mention many of the companies for which we consult) are staunchly anti-Windows; I wanted to help demonstrate that Mono could be a viable alternative for non-Windows development. But research into the state of the community left me disappointed: PRs are ignored, roadmaps are horribly out of date, builds are constantly broken...in general, not an environment that encourages community members to contribute their valuable time. I understand the desire to maintain a high standard for contributed code, and I support maintaining that standard; but a process MUST be developed that encourages community contribution rather than stagnating it. On Thu, Oct 16, 2014 at 3:31 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, The best approach is to stay engaged in the pull requests and bring the attention to the mailing list for us to discuss. Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. The bar for mono is high: we can not just take any code and distribute it, since the impact of mistakes is large. To give an example, even new Xamarin employees that are hired to work exclusively on the runtime are working through pull requests, and they also have to wait for some of the more senior people to review and approve the patches. We have very nice fixes that we still postpone until we have the
Re: [Mono-dev] Pull Requests
Hi Miguel, I have considered helping out by commenting on PR's, however, I've always felt that I'm not nearly experienced enough to have my opinion/view respected by the committer. I definitely think forcing/gently encouraging people to create a discussion on mailing list to ask for review would help. Maybe a format for the subject? i.e. PR#1123 - short description. this would help people filter if they so desire. I think if that is the position though, there needs to be a way to say non-contributors have said it's ok, let's get a proper review now. I'm not sure how you could do that though, is there a workflow in GitHub that could help? maybe something you have at Xamarin that could be re-used? I'm going to try and help out with a few this week and we'll see how it goes. Thanks, Martin. On 16 October 2014 22:28, Miguel de Icaza mig...@xamarin.com wrote: Let me add a couple of points. First, I have noticed is that: - Contributors do not make a habit out of checking pull requests; I know I don't - GitHub is too chatty, so everyone I know just filters notifications. I suspect this is why anyone being assigned issues just ignores them. There is just too much traffic. Mono historically took patches from the mailing list. Not from github pull requests. So culturally, this was never aligned, it just kind of happened, and we kind of never evolved or changed with it. Perhaps what we need is for these pull requests to be posted here on the list and discussed here on the list. I think this is better, as we have a place where the larger community can comment on patches. It would surface the discussion to everyone, as opposed to limiting it to those that happen to stumble on the pull requests or visit the page. Second, I think there is a room for folks to contribute to this process, even if they are not committers, or active contributors. Someone that could shepherd a contributor and the contribution. Many of the patches do not meet the basic requirements for a patch review, and we end up wasting valuable time on them. Things that we would need: - An actual detailed explanation of the change. Many patches are submitted with very little information. - Test cases: many patches are contributed without tests to show the problem as it is today nor to ensure that the code does not regress. - Style: many patches contain white space changes, unnecessary refactoring and changes that are not suitable to be contributed. - Rebasing: many patches are contributed and fixes are piled on top of each other. The result is not suitable to be merged as it would essentially pollute the commit history. So someone that can assist the less sophisticated among us to squash the commits would help. - Patches that change the surface and contain no documentation. - Steering developers to discuss the patches on the mailing list and following up directly on the mailing list with the reviewers to ensure that the patches can be merged. I think the above would help us tremendously to accelerate the patch review process. Miguel On Thu, Oct 16, 2014 at 4:30 PM, Miguel de Icaza mig...@xamarin.com wrote: There is no point in starting a discussion where you are going to cherry pick facts for the sake of your argument. As for contributing, which one of *your* pull requests have been pending and not being reviewed? Because we would like to provide you with the valuable feedback that you need to turn these contributions into patches. Miguel On Thu, Oct 16, 2014 at 4:25 PM, David Nelson eatdrinksleepc...@gmail.com wrote: Long term, the ideal situation is one where we can give more people commit rights, and review rights. But until we have developed the skills in the community that are needed, we will continue with the current setup. This seems to be a chicken-and-egg problem. We need to christen more reviewers in order to handle the volume of PRs and keep the Mono community engaged; but in order to gain enough confidence in a contributor to make them a reviewer, their requests need to be reviewed! How can we develop the skills in the community if requests routinely sit idle for over a year? I got really excited about contributing to Mono about two years ago; I love .NET and C#, but many of my colleagues (not to mention many of the companies for which we consult) are staunchly anti-Windows; I wanted to help demonstrate that Mono could be a viable alternative for non-Windows development. But research into the state of the community left me disappointed: PRs are ignored, roadmaps are horribly out of date, builds are constantly broken...in general, not an environment that encourages community members to contribute their valuable time. I understand the desire to maintain a high standard for contributed code, and I support maintaining that standard; but a process MUST be developed
[Mono-dev] Pull requests on bug fixes
Hi, lastly I posted two pull requests corresponding to bugs founded in bugzilla. One of these has even already be closed, however nobody showed interesting in pulling my changes or rejecting them. Could anyone with privileges check it out? One can find requests here: https://github.com/mono/mono/pull/92 https://github.com/mono/mono/pull/93 -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
