Boost logo

Boost :

Subject: Re: [boost] [winrt support] Adding support for Windows 8 store/phone to Boost libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-04-29 06:12:53


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/



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk