Re: [Mono-dev] Building mono on Windows issues.
Hi Jonathan, Thanks for taking the time to provide the background. I understand/agree that facilitating development on Windows is a complex task. I've seen some of the emails over time and can well imagine it's complex and invasive to the existing build system. People start the work, but I''ve not seen anything come out of it. If I take my scope as something much simpler, which is just to facilitate building Mono on Windows from scratch, on a vanilla Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I think that's much more achievable. I have been looking at this since 3.4.0 and the main issues I have encountered were having the right dependencies, idiosyncracies of the build tools, and issues with releases such as missing files/problems with Cygwin headers. Perhaps very few of us are fit for purpose when it comes to actually _contributing_ to Mono, but I can well understand that the first step an OpenSource developer wants to make is to compile a project from source and run up the results. I can also understand the frustration when you've spent a couple of days on this and just keep encountering problems. People can then give up in frustration. Even the longest journey begins with a single step and it strikes me that it would be a useful thing to facilitate newbies building on Windows to get them going on that journey, even if that's just by documenting issues they will encounter. The emails I get from individuals show me that when they do have the information they need to build Mono, and how to work around the gotchas, then they can do it with relative ease. - it's an amalgam of tools, which constantly update. There was never an easy way to duplicate a working setup from one machine to the next I agree, but that's an issue with any complex software project with build dependencies surely? I work with Yocto Embedded Linux builds and I can tell you that it's even more difficult there, but they manage it extremely well. To address this seems to me a matter of understanding/documenting the dependencies and, where necessary, defining the require versions of those dependencies to ensure a build works in a controlled manner. I am making an assumption that the dependencies are all on Cygwin (are there any others?). If so then it should be relatively straightforward to define the version of Cygwin to use and/or pull down specific versioned packages. It was suggested to me that a setup script that pulled down appropriate dependencies would be useful, and I agree. I have been meaning to do something on that as I think it is straightforward but haven't yet had the time. If this was to be in place do you think there would be any other toolchain issues that would need consideration? This was done with cygwin and was packaged by an additional installer step. The installer step was never very transparent so I can't comment on that. Somebody somewhere must have been building the Windows installer, at least up until 3.2.3. I believe it would be helpful if somebody could take time to explain how this works or just provide the automation to build the installer. When we execute the 'make install' step what results on Windows is missing key files such as 'mono.exe' and instead has Linux stubs such as 'mono' which causes problems. I would like to understand how the install step is supposed to work and to try to fix it instead of having to manually fix it up each time. Similarly I would like to be able to generate a non-official installer in the same way as the official installer is built, which at least people could then use in the absence of an official installer. given the size and complexity of the mono build and tests, it was generally not robust. Especially for continuous and automated usage My experience is that once the issues with any given release are addressed then it builds reliably. Master is of course a different beast but I am not looking at supporting a build from an arbitrary commit here. - it was slow. Slow as in hours on Windows vs minutes on Linux Yes, my guess is that it's perhaps related to forking on Windows under Cygwin but who knows. It would be nice to have a faster build but, for example, building a Yocto image can take many, many hours. (And don't get me started on WindowsCE...) I think people can live with this if it actually builds for them. To me a first pass at needed actions are: - define one or more supported Windows build host platforms. - take the latest Mono 3.10.0 release and create an installer script for versioned build dependencies - create a simple build script and test script - understand how the packaging step works and automate this - fix issues with installation of Mono files that aren't currently correct under Windows (e.g. mono 3.8.0 mono.exe, perhaps fixed in 3.10.0) - fix issues with needing to change Cygwin headers for the compile to work. - setup a CI system building and reporting for master. Ideally, as I've said
Re: [Mono-dev] Building mono on Windows issues.
Hi Guys, I took it upon myself to try and get a build up and running on Appveyor yesterday. Please have a look at https://github.com/mika76/mono and https://ci.appveyor.com/project/mmihajlovic/mono - so far the only thing I've edited is the appveyor.yml file and the actual a[[veyor settings. At the moment it is installing cygwin and packages and running the visual studio msbuild file - which seems not to work - it fails with compiler out of heap space error. If the msbuild does not pan out, the cygwin build can always be attempted as well. If anybody wants to help, let me know and I'll make you a contributor on the repository. Cheers, Mladen On 17 October 2014 08:46, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: Hi Jonathan, Thanks for taking the time to provide the background. I understand/agree that facilitating development on Windows is a complex task. I've seen some of the emails over time and can well imagine it's complex and invasive to the existing build system. People start the work, but I''ve not seen anything come out of it. If I take my scope as something much simpler, which is just to facilitate building Mono on Windows from scratch, on a vanilla Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I think that's much more achievable. I have been looking at this since 3.4.0 and the main issues I have encountered were having the right dependencies, idiosyncracies of the build tools, and issues with releases such as missing files/problems with Cygwin headers. Perhaps very few of us are fit for purpose when it comes to actually _contributing_ to Mono, but I can well understand that the first step an OpenSource developer wants to make is to compile a project from source and run up the results. I can also understand the frustration when you've spent a couple of days on this and just keep encountering problems. People can then give up in frustration. Even the longest journey begins with a single step and it strikes me that it would be a useful thing to facilitate newbies building on Windows to get them going on that journey, even if that's just by documenting issues they will encounter. The emails I get from individuals show me that when they do have the information they need to build Mono, and how to work around the gotchas, then they can do it with relative ease. - it's an amalgam of tools, which constantly update. There was never an easy way to duplicate a working setup from one machine to the next I agree, but that's an issue with any complex software project with build dependencies surely? I work with Yocto Embedded Linux builds and I can tell you that it's even more difficult there, but they manage it extremely well. To address this seems to me a matter of understanding/documenting the dependencies and, where necessary, defining the require versions of those dependencies to ensure a build works in a controlled manner. I am making an assumption that the dependencies are all on Cygwin (are there any others?). If so then it should be relatively straightforward to define the version of Cygwin to use and/or pull down specific versioned packages. It was suggested to me that a setup script that pulled down appropriate dependencies would be useful, and I agree. I have been meaning to do something on that as I think it is straightforward but haven't yet had the time. If this was to be in place do you think there would be any other toolchain issues that would need consideration? This was done with cygwin and was packaged by an additional installer step. The installer step was never very transparent so I can't comment on that. Somebody somewhere must have been building the Windows installer, at least up until 3.2.3. I believe it would be helpful if somebody could take time to explain how this works or just provide the automation to build the installer. When we execute the 'make install' step what results on Windows is missing key files such as 'mono.exe' and instead has Linux stubs such as 'mono' which causes problems. I would like to understand how the install step is supposed to work and to try to fix it instead of having to manually fix it up each time. Similarly I would like to be able to generate a non-official installer in the same way as the official installer is built, which at least people could then use in the absence of an official installer. given the size and complexity of the mono build and tests, it was generally not robust. Especially for continuous and automated usage My experience is that once the issues with any given release are addressed then it builds reliably. Master is of course a different beast but I am not looking at supporting a build from an arbitrary commit here. - it was slow. Slow as in hours on Windows vs minutes on Linux Yes, my guess is that it's perhaps related to forking on Windows under Cygwin but who knows. It would be nice to have a
Re: [Mono-dev] Building mono on Windows issues.
Hi Mladen, Sounds good to me. I've not encountered Appveyor before but it looks good. How do you get the Cygwin dependencies in there? Can it be assumed that what's happening in the Appveyor build is basically the same as on a standard Windows box? Cheers, Alex On 17/10/2014 08:53, Mladen Mihajlovic wrote: Hi Guys, I took it upon myself to try and get a build up and running on Appveyor yesterday. Please have a look at https://github.com/mika76/mono and https://ci.appveyor.com/project/mmihajlovic/mono - so far the only thing I've edited is the appveyor.yml file and the actual a[[veyor settings. At the moment it is installing cygwin and packages and running the visual studio msbuild file - which seems not to work - it fails with compiler out of heap space error. If the msbuild does not pan out, the cygwin build can always be attempted as well. If anybody wants to help, let me know and I'll make you a contributor on the repository. Cheers, Mladen On 17 October 2014 08:46, Alex J Lennon ajlen...@dynamicdevices.co.uk mailto:ajlen...@dynamicdevices.co.uk wrote: Hi Jonathan, Thanks for taking the time to provide the background. I understand/agree that facilitating development on Windows is a complex task. I've seen some of the emails over time and can well imagine it's complex and invasive to the existing build system. People start the work, but I''ve not seen anything come out of it. If I take my scope as something much simpler, which is just to facilitate building Mono on Windows from scratch, on a vanilla Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I think that's much more achievable. I have been looking at this since 3.4.0 and the main issues I have encountered were having the right dependencies, idiosyncracies of the build tools, and issues with releases such as missing files/problems with Cygwin headers. Perhaps very few of us are fit for purpose when it comes to actually _contributing_ to Mono, but I can well understand that the first step an OpenSource developer wants to make is to compile a project from source and run up the results. I can also understand the frustration when you've spent a couple of days on this and just keep encountering problems. People can then give up in frustration. Even the longest journey begins with a single step and it strikes me that it would be a useful thing to facilitate newbies building on Windows to get them going on that journey, even if that's just by documenting issues they will encounter. The emails I get from individuals show me that when they do have the information they need to build Mono, and how to work around the gotchas, then they can do it with relative ease. - it's an amalgam of tools, which constantly update. There was never an easy way to duplicate a working setup from one machine to the next I agree, but that's an issue with any complex software project with build dependencies surely? I work with Yocto Embedded Linux builds and I can tell you that it's even more difficult there, but they manage it extremely well. To address this seems to me a matter of understanding/documenting the dependencies and, where necessary, defining the require versions of those dependencies to ensure a build works in a controlled manner. I am making an assumption that the dependencies are all on Cygwin (are there any others?). If so then it should be relatively straightforward to define the version of Cygwin to use and/or pull down specific versioned packages. It was suggested to me that a setup script that pulled down appropriate dependencies would be useful, and I agree. I have been meaning to do something on that as I think it is straightforward but haven't yet had the time. If this was to be in place do you think there would be any other toolchain issues that would need consideration? This was done with cygwin and was packaged by an additional installer step. The installer step was never very transparent so I can't comment on that. Somebody somewhere must have been building the Windows installer, at least up until 3.2.3. I believe it would be helpful if somebody could take time to explain how this works or just provide the automation to build the installer. When we execute the 'make install' step what results on Windows is missing key files such as 'mono.exe' and instead has Linux stubs such as 'mono' which causes problems. I would like to understand how the install step is supposed to work and to try to fix it instead of having to manually fix it up each time. Similarly I would like to be able to generate a non-official installer in the same way as the official installer is built,
Re: [Mono-dev] Building mono on Windows issues.
Hey Alex There's a lot that you can do through their yml settings file. Download and setup pretty much anything. Have a look in the root if the repo: appveyor.yml. On 17 Oct 2014 8:59 AM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: Hi Mladen, Sounds good to me. I've not encountered Appveyor before but it looks good. How do you get the Cygwin dependencies in there? Can it be assumed that what's happening in the Appveyor build is basically the same as on a standard Windows box? Cheers, Alex On 17/10/2014 08:53, Mladen Mihajlovic wrote: Hi Guys, I took it upon myself to try and get a build up and running on Appveyor yesterday. Please have a look at https://github.com/mika76/mono and https://ci.appveyor.com/project/mmihajlovic/mono - so far the only thing I've edited is the appveyor.yml file and the actual a[[veyor settings. At the moment it is installing cygwin and packages and running the visual studio msbuild file - which seems not to work - it fails with compiler out of heap space error. If the msbuild does not pan out, the cygwin build can always be attempted as well. If anybody wants to help, let me know and I'll make you a contributor on the repository. Cheers, Mladen On 17 October 2014 08:46, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: Hi Jonathan, Thanks for taking the time to provide the background. I understand/agree that facilitating development on Windows is a complex task. I've seen some of the emails over time and can well imagine it's complex and invasive to the existing build system. People start the work, but I''ve not seen anything come out of it. If I take my scope as something much simpler, which is just to facilitate building Mono on Windows from scratch, on a vanilla Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or whatever, then I think that's much more achievable. I have been looking at this since 3.4.0 and the main issues I have encountered were having the right dependencies, idiosyncracies of the build tools, and issues with releases such as missing files/problems with Cygwin headers. Perhaps very few of us are fit for purpose when it comes to actually _contributing_ to Mono, but I can well understand that the first step an OpenSource developer wants to make is to compile a project from source and run up the results. I can also understand the frustration when you've spent a couple of days on this and just keep encountering problems. People can then give up in frustration. Even the longest journey begins with a single step and it strikes me that it would be a useful thing to facilitate newbies building on Windows to get them going on that journey, even if that's just by documenting issues they will encounter. The emails I get from individuals show me that when they do have the information they need to build Mono, and how to work around the gotchas, then they can do it with relative ease. - it's an amalgam of tools, which constantly update. There was never an easy way to duplicate a working setup from one machine to the next I agree, but that's an issue with any complex software project with build dependencies surely? I work with Yocto Embedded Linux builds and I can tell you that it's even more difficult there, but they manage it extremely well. To address this seems to me a matter of understanding/documenting the dependencies and, where necessary, defining the require versions of those dependencies to ensure a build works in a controlled manner. I am making an assumption that the dependencies are all on Cygwin (are there any others?). If so then it should be relatively straightforward to define the version of Cygwin to use and/or pull down specific versioned packages. It was suggested to me that a setup script that pulled down appropriate dependencies would be useful, and I agree. I have been meaning to do something on that as I think it is straightforward but haven't yet had the time. If this was to be in place do you think there would be any other toolchain issues that would need consideration? This was done with cygwin and was packaged by an additional installer step. The installer step was never very transparent so I can't comment on that. Somebody somewhere must have been building the Windows installer, at least up until 3.2.3. I believe it would be helpful if somebody could take time to explain how this works or just provide the automation to build the installer. When we execute the 'make install' step what results on Windows is missing key files such as 'mono.exe' and instead has Linux stubs such as 'mono' which causes problems. I would like to understand how the install step is supposed to work and to try to fix it instead of having to manually fix it up each time. Similarly I would like to be able to generate a non-official installer in the same way as the official installer is built, which at least people could then use in
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] Windows builds
From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Bryan Crotaz Who's with me? FWIW, the state of mono for windows is really really bad, but it's not great for rhel or ubuntu either. I agree *enormously* that there's a big benefit to improving the state of all these. So FWIW I agree with you. But I don't have time to contribute. (tangent) The issue with the rhel/ubuntu setup is this: As long as you build from source, it's pretty straightforward and reliable. But as bugfixes and security patches get released, nobody will make a habit of literally building every time there's an update, in order to keep their systems up to date. There needs to be officially maintained yum apt repos - which there are - but that's the problem. The yum apt repos seem to be in a perpetual state of brokenness. When we ask about it here, the answer is always just wait a few hours or a day and try again, which doesn't seem to work, and doesn't really help IT people out there maintain their systems anyway. ___ 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
Re: [Mono-dev] Building mono on Windows issues.
On 17/10/2014 16:07, Alex J Lennon wrote: On 17/10/2014 09:09, Mladen Mihajlovic wrote: Hey Alex There's a lot that you can do through their yml settings file. Download and setup pretty much anything. Have a look in the root if the repo: appveyor.yml. Hi Mladen, I like the look of Appveyor a lot. Thanks for that. I've been getting going with the configuration file and in parallel testing the 3.10.0 release builds locally under cygwin as a sanity check and because each time I test a build with AppVeyor it starts from a clean OS image (not a bad thing) which means it takes a long time to clone the Mono repo before the build starts. Unfortunately the Windows build of release 3.10.0 fails locally: libtool: compile: i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono -I../../libgc/include -I../../eglib/src -I../../eglib/src -DWINVER=0x0502 -D_WIN32_WINNT=0x0502 -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS -DFD_SETSIZE=1024 -g -O2 -fno-strict-aliasing -fwrapv -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value -mno-tls-direct-seg-refs -Werror-implicit-function-declaration -MT sha1.lo -MD -MP -MF .deps/sha1.Tpo -c sha1.c -DDLL_EXPORT -DPIC -o .libs/sha1.o In file included from sha1.c:20:0: ./sha1.h:25:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' sha1.c:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef' sha1.c: In function 'SHA1Transform': sha1.c:71:2: error: 'CHAR64LONG16' has no member named 'l' It looks like perhaps the mono-3.10.0-branch needs Vincent's commit cherry-picking Use G_BEGIN_DECLS instead of __BEGIN_DECLS. https://github.com/mono/mono/commit/3c920be3e534c8c2d51695f16055e84936fe761e How would we go about flagging that up with somebody to ask them to look into it? Regards, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gc
Hi, We were helping someone who was having performance problems with a large streaming application that they run under .NET and mono. On .NET the app takes around 7-10 seconds to do its stuff. On Mono on Linux it was taking 47 seconds or so to do the same thing. The mono system had 256G RAM and 48 cores. When they used Mono on Windows the figure was back to around 7 seconds. We suggested they use MONO_GC_DEBUG to try and determine where they were spending time. It turns out that the old generation scan was responsible for nearly all of the difference between the runs (i.e. around 40 seconds). How (or does) does the sgen gc differ under Windows to Linux? Neale ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Review of PR1349
Disclaimer: I know nothing about these classes. That said, I firmly support the plan to bring PRs into the mailing list, and would hate to see such a great plan get no love, so I want to say that from looking at these (very small and easily digested) changes, they at least look clean and good. From a fellow user of Mono who is interested in its success and expansion (with no say in any outcomes here), thanks for doing this. On Oct 16, 2014 6:23 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi all, I've just put up my attempt at getting the MachineKey.Protect and Unprotect methods available in mono. I'd be grateful if someone give it a quick review to make sure it makes sense. https://github.com/mono/mono/pull/1349 Couple of notes. There is no compatibility with encrypted items that were done using Windows. This is a barebones implementation in that it will work and be at least as secure as MachineKey.Encrypt/Decrypt (as it uses the same methods under the hood). This is my first PR for mono, so please be kind. I've tried my best to follow the coding guidelines, but I'm happy to make changes. Thanks Martin ___ 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] Review of PR1349
Thanks Chris, The main thing I think will be off benefit with people reviewing is simply getting that second pair of eyes to sanity check it. Looking for basic coding standards stuff, anything obvious. Other things like advice on separating things out etc. On 17 October 2014 20:46, Chris Rogus cricel...@gmail.com wrote: Disclaimer: I know nothing about these classes. That said, I firmly support the plan to bring PRs into the mailing list, and would hate to see such a great plan get no love, so I want to say that from looking at these (very small and easily digested) changes, they at least look clean and good. From a fellow user of Mono who is interested in its success and expansion (with no say in any outcomes here), thanks for doing this. On Oct 16, 2014 6:23 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi all, I've just put up my attempt at getting the MachineKey.Protect and Unprotect methods available in mono. I'd be grateful if someone give it a quick review to make sure it makes sense. https://github.com/mono/mono/pull/1349 Couple of notes. There is no compatibility with encrypted items that were done using Windows. This is a barebones implementation in that it will work and be at least as secure as MachineKey.Encrypt/Decrypt (as it uses the same methods under the hood). This is my first PR for mono, so please be kind. I've tried my best to follow the coding guidelines, but I'm happy to make changes. Thanks Martin ___ 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-dev] Unit Testing process: Community Contributions
This might have gotten buried in the other thread. So here's a new thread to bring it up to attention. Miguel, this question is probably for you. (And by the way, thank you for everything, and especially thank you for participating here.) The bottleneck that's preventing much community contribution is *primarily* the fear of community contributions breaking other things. 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
Re: [Mono-dev] Unit Testing process: Community Contributions
Hello, The build bot does some of this work when you submit a pull request. It does not cover all platforms, nor all configurations, but it is a good first step. But this is not a problem. Not every patch affects all systems, and most of the code is cross platform, so testing on one is enough. On Fri, Oct 17, 2014 at 5:38 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: This might have gotten buried in the other thread. So here's a new thread to bring it up to attention. Miguel, this question is probably for you. (And by the way, thank you for everything, and especially thank you for participating here.) The bottleneck that's preventing much community contribution is *primarily* the fear of community contributions breaking other things. 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Closing Pulls
Hi All, This is probably more a question for Miguel, but I thought I'd make it public. I'm looking through the list of PR's (103 at the moment) and I thought it best to go from the end. However, it seems like most of these are either done by someone who no longer has interest in contributing, or probably no longer relevant. I'm wondering whether the best option here is to try and put a bit of a hardline policy for a short time to get the list to a more manageable number, and make sure that PR's will be responded to and updated by the commiter. What I'm thinking is, ping the commiter, give them 1 week to respond (in some way, not necessarily update it, just acknowledge it). After that simply close it. The goal here is that if the list is smaller, so the contributors actually feel that clearing the queue is an achievable task. For this to work, I'm thinking we (I'm happy to dedicate some time to this) could just ping the mailing list to ask you close them Miguel? I'm thinking it's an easy and quick thing to do, so we can expect a fairly quick turnaround? Any thoughts welcome. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Closing Pulls
For this to work, I'm thinking we (I'm happy to dedicate some time to this) could just ping the mailing list to ask you close them Miguel? I'm thinking it's an easy and quick thing to do, so we can expect a fairly quick turnaround? I dont think they hurt to keep them open. Do not want to throw the baby with the bath water. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Closing Pulls
Thanks Miguel, I appreciate why you would want to keep them, however, do you not feel the list is currently unmanageable? Maybe we could add labels (the ones in GitHub, not used them before but it looks like it could work) to the older ones like inactive so we know which ones are worth reviewing and can filter them out? On 17 October 2014 23:17, Miguel de Icaza mig...@xamarin.com wrote: For this to work, I'm thinking we (I'm happy to dedicate some time to this) could just ping the mailing list to ask you close them Miguel? I'm thinking it's an easy and quick thing to do, so we can expect a fairly quick turnaround? I dont think they hurt to keep them open. Do not want to throw the baby with the bath water. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Closing Pulls
I would like to add that, on the Metasploit framework, we often have 80+ pull requests open at any given point in time, and labels in Github are *so* useful. https://github.com/rapid7/metasploit-framework/pulls On Fri, Oct 17, 2014 at 5:27 PM, Martin Thwaites monofo...@my2cents.co.uk wrote: Thanks Miguel, I appreciate why you would want to keep them, however, do you not feel the list is currently unmanageable? Maybe we could add labels (the ones in GitHub, not used them before but it looks like it could work) to the older ones like inactive so we know which ones are worth reviewing and can filter them out? On 17 October 2014 23:17, Miguel de Icaza mig...@xamarin.com wrote: For this to work, I'm thinking we (I'm happy to dedicate some time to this) could just ping the mailing list to ask you close them Miguel? I'm thinking it's an easy and quick thing to do, so we can expect a fairly quick turnaround? I dont think they hurt to keep them open. Do not want to throw the baby with the bath water. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- http://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
