On 28 Apr 2014 at 11:14, stgates wrote:
Having recently been dismissed from a similar multinational where publicly contributing to open source except through your wife's name is career damaging/destroying, I firstly want to thank you personally for taking the time, effort and risk in the above.
Thanks. To be clear here Microsoft is aware of this work, and is evolving. It isn't something being done only in my spare time. Microsoft is getting much better about open source. For example I also work on a C++ open source project, the C++ Rest SDK https://casablanca.codeplex.com/ .
That's Artur's thing isn't it? If you work with him, do say hi to him for me. Ale too, he was cool. Separately, when I was interviewing at Microsoft you had just hired Gabriel dos Reis who is very well known in open source. As other posters have mentioned, your experience in a large org as someone known in open source can vary widely - you may attract your own personal hate group within the company, or you may actually get promoted. You can probably guess which I got, but ah well.
By unnecessary, I mean, for example, if you added a separate CreateEventEx implementation just for WinRT when clearly the Win32 implementation could be modified to work on both Win32 and WinRT.
Yes I completely agree and this is exactly what I did :). For example instead of just using CreateEventEx for only WinRT I instead made changes to use CreateEventEx to always be used so it works in Win32 and WinRT.
Excellent. Your patch looks good then. It'll just be everything else to get past: politics, inertia, not-a-real-problem-ness, etc
You'll get far further and quicker if you can demonstrate that your changes cause no regressions and add very little new complexity, and it helps to include soak tests. Also, you'll need to write a ton of documentation for anything added. See below for an idea to generate some goodwill.
I agree, I'm running all the tests to make sure we don't introduce any regressions. I assume a requirement by any library maintainer would be to not regress or break tests.
Unless there is a very good reason e.g. the old tests were actually hiding a problem, then yes.
If you can supply a feed of regular Boost regression testing for WinRT (especially if on ARM as well), I think you'd get lots of very positive goodwill in return here. This basically involves setting up a local machine testing per commit which sends the XML with the results to one of Boost's servers. If this is an option, do say so and I'm sure the relevant people will chime in.
Ok this is something I will think about exploring.
Thanks for the tips,
No problem. I've been where you're now at, and you have my every support. I must admit I failed to release a single line of open source during my entire time with my previous employer, despite writing thousands of lines of code which were intended by my management to be so released. I certainly didn't get any lines of code into any actual open source. BTW, I'll shortly be coming to this list with a new sync object for Boost.Thread called a "permit object" which wraps the failed POSIX pthreads permit object proposal for C11 which solves some of the problems of using condition variables directly. It looks a bit like half of a Win32 event object, but has stronger guarantees. Anyway it'll need to be reviewed here before it can enter Boost.Thread, so it may be useful for you to watch that process unfold to give you an idea of what may be involved with your patchset as a good chunk of yours also involves Boost.Thread. You might see something next week or so, or after the C++ Now conference. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/