[Scons-dev] stubprocess ?

[Jason Kenny]

HI Dirk.

I cannot speak to what Vasily or Eugene can do with tweaking this code as use suggest. I however can speak to the some legal stuff here and a technical issue.

First the technically issue. The point of the patch was that we had found that the “default” forking was a major slow down to the build on Linux. This became a bigger issue when we updated to a newer RHEL setup for the default OS to build some products. It was shown that this “stubprocess” as we had modified subprocess which was used in Parts override to SPAWN made everything faster on any POSIX based OS ( windows was fast already in this case). From a design point of view I totally get the idea to make this easier to switch between the modified subprocess and the “default” version of subprocess. I think what we are missing in SCons for this is a global “set” of Spawn value. The current setup as is requires Parts to set SPAWN for every environment we make/clone. I believe the IAPAT (based on Gregs N notes) stuff I am trying to implement in Parts as the Setting object would help address this problem better than some tweak to a default Environment.

Before I was let go from Intel I had finished the work with Parts and SCons open source work sharing. Eugene and Vasily are in the clear to share code with Parts and should be ok with SCons as long as they are employed at Intel ( They can double check Scons part with Serge P). Everything in Parts is safe for SCons to take and use. This has always been the case. As this work is derived from Parts work, this is already covered. Ideally we could get stuff in Parts faster than it would be to get it in to SCons given the “history” of SCons. What I did not finish, but looks like I have to set this up as with my employ at Yahoo is setting up a developer attestation, or code release form. Basically saying that any code coming in from a given developer does not have any stolen code or IP and that it is free to be used by project. SCons does not have such a form. I believe the SCons foundation needs to have this. Which is basically a legal blub saying what I stated above the developer can say they agree to in an e-mail or a pull request. Given the lack of this there was not a more formal way to say this code form Parts is OK to be used in SCons.

I think a more official “code release” process could be done in SCons this would help make this easier.

We have the text for Intel in the Parts MIT license. 
I should note the Yahoo and Intel approvers for Open source work are communicating to me that they may like a change to the license in the we have a contributor list vs the names in MIT license file. Given the holidays the details of the proposed changed has note been fully communicated yet. It has something to do with being less “messy” in the unlikely case there was some legal issue with some person. I can communicate more on that once I get some resolution. 

(Honestly I never knew open source project could be so much “extra” work) 

Hope this helps.
Jason

From: Dirk Bächle
Sent: Sunday, December 27, 2015 6:01 AM
To: scons-dev at scons.org
Subject: Re: [Scons-dev] stubprocess ?

Hi Vasily,

On 23.12.2015 22:04, Vasily wrote:
> Hi Bill and all,
> Since we (Eugene - added, and me) were original authors, maybe we should work on making a pull request.
> Can you share the requirements for successful pull request?
>
> P.S. I think that making an env opt-out key is hard to do since it monkey-patches subprocess module globally, but making an
> command-line option might be a good idea.
>

thanks for offering your help with this. I agree that we shouldn't care about an option for switching the stubprocess wrapper off. 
As far as I remember we discussed this some time ago, and the consensus was to always activate the wrapper under "posix"-like systems.

One remark though: Can we possibly rename the patched subprocess call to a different module? For our purposes (in SCons) we don't 
need a global replacement, but just a method that we can stuff into our env["SPAWN"] variable which gets used for every command-line 
action that has to get executed.
What I have observed is, that the global replacement of "subprocess" gives trouble when custom Builders or SConscripts do an
"import subprocess" again afterwards. How do we protect against this? If possible I'd like to have the wrapper decoupled from the 
"subprocess" module...

For the pull request, please fork the current "trunk" from the main repo as described at

   https://bitbucket.org/scons/scons/wiki/DeveloperGuide/Introduction

. The section "Fixing and developing the core sources" should get you going...if you have any questions, feel free to ask please. 
 From my point of view, you won't have to provide any additional tests or documentation. We just have to ensure that all the current 
tests still work afterwards...and then there's one more detail: Licensing and copyrights. I'm not sure what the state of the 
stubprocess wrapper is, regarding copyright. I assume that it was (at least partly) developed during your work time for Intel, so we 
(SCons foundation) should get a document (email might be enough?, but I'm not a lawyer) allowing us to distribute the wrapper 
together with our sources, under the same MIT license (we'd mention Intel and your names in the copyright, can you make a proposal 
for the exact text?). I'd really like to have this in writing somehow...

That's what I can think of for the moment...happy hackin'! ;)

Best regards,

Dirk

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20151227/9e3ceb3f/attachment-0001.html>