Re: [Scons-dev] catching up
On Mon, Aug 25, 2014 at 1:52 AM, Dirk Bächle tshor...@gmx.de wrote: On 24.08.2014 21:02, anatoly techtonik wrote: On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: Then I'd like to revisit Mercurial workflow, because we need to clarify how to rebase pull requests. I would really like to understand why we need a rebase for pull requests in the first place. 1. To get clean linear history, which humans can browse without advanced graphical tools. 2. To resolve conflicts. Just for example https://bitbucket.org/scons/scons/pull-request/155/adds-a-test-case-demonstrating-that-issue/diff#Ltest/SWIG/include-directive.pyT59 2.1 To update CHANGES.txt after other PR did this 3. Addressing review comments 4. Testing PR on top of other fixes 5. Squashing commits 6. Moving stuff to a different branch 7. Finally a reason to know Mercurial better I see these two features - stubprocess.py and __slots__ as branches (ideally all feature should be optional, so that you can turn off them, for example for porting code to Lua). Lua, what? Where does that suddenly come from? I don't see any porting activities to other languages on the roadmap, and I don't remember any discussions about it either. So why should we give our current development a direction based on imaginary features? Sorry, it is just a bit of forward thinking. The same stuff that made me mad when I saw the Docbook toolchain committed. Last time I tried to clone SCons over SSH it took 20 minutes and I knew it will happen. As for Lua. Right now there are better systems than SCons in some aspects, for example http://industriousone.com/premake in Lua which is absent from http://scons.org/wiki/SconsVsOtherBuildTools and http://martine.github.io/ninja/ used by Chromium guys, who I believe ditched SCons at some point even though they've built a Hammer harness on top of it. The reason why such tools appear is that the old code base becomes too overcomplicated for new features to add, and I am afraid that people primarily abandon projects for this reason. I want to be able to compare architecture of SCons to other tools at any point in time in build tool evolution, that's why if any low-level optimizations are to be performed at the cost of simplicity, it would be nice if some thought was put into how to make them less obtrusive. I am not using SCons for any project at all, so the time that I can spend on is not replenished from any 'job reserves' and the only thing I am really interested is to get visualization of its internals, just because I am curious. There is still a dozen of other ideas, but I don't think they are worthy to be added to Roadmap or even discussed until production level issues are resolved. BTW, it would be nice if somebody merge yet another fix for Python 2.6 buildbot: https://bitbucket.org/scons/scons/pull-request/179/03-fixed-used-imports-that-failed-on/diff Thanks. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
Hi guys, We made some types safety tweaks in the subprocess we provided. I have attached it. This is the latest version in Parts open source as well ( ie in truck). Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary Oberbrunner Sent: Sunday, August 24, 2014 1:09 PM To: Dirk Bächle; SCons developer list Subject: Re: [Scons-dev] catching up On Sun, Aug 17, 2014 at 5:36 PM, Dirk Bächle tshor...@gmx.demailto:tshor...@gmx.de wrote: On 17.08.2014 20:54, Gary Oberbrunner wrote: There's probably not much point in my trying to respond to many of the threads that have been running here in the last couple of weeks; if there are things that should be addressed please bring them up. As for dev priorities, I think we have two big important projects (not counting releasing 2.3.3 which I guess we should do after some further testing?): Python 3 port, and Toolchain. [...] (I know there are lots of other things going on -- I didn't intend the above to be exhaustive.) Making this a little more complete: - patch/bug release 2.3.3? (fix for D tools) - Node class patch (switch to __slots__) - Integration of stubprocess.py - release 2.4? - then, Python3 and Toolchain? OK, step 1's complete. Next up, __slots__ and stubprocess. Both of those will need more testing than usual. We could do a checkpoint release, or just announce on the user list when they're in. -- Gary stubprocess.py Description: stubprocess.py ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
Looks like some of the memory clean up may have broken interactive mode. Take a look at: http://scons.tigris.org/issues/show_bug.cgi?id=2971 On Mon, Aug 25, 2014 at 8:42 AM, Kenny, Jason L jason.l.ke...@intel.com wrote: Hi guys, We made some types safety tweaks in the subprocess we provided. I have attached it. This is the latest version in Parts open source as well ( ie in truck). Jason *From:* Scons-dev [mailto:scons-dev-boun...@scons.org] *On Behalf Of *Gary Oberbrunner *Sent:* Sunday, August 24, 2014 1:09 PM *To:* Dirk Bächle; SCons developer list *Subject:* Re: [Scons-dev] catching up On Sun, Aug 17, 2014 at 5:36 PM, Dirk Bächle tshor...@gmx.de wrote: On 17.08.2014 20:54, Gary Oberbrunner wrote: There's probably not much point in my trying to respond to many of the threads that have been running here in the last couple of weeks; if there are things that should be addressed please bring them up. As for dev priorities, I think we have two big important projects (not counting releasing 2.3.3 which I guess we should do after some further testing?): Python 3 port, and Toolchain. [...] (I know there are lots of other things going on -- I didn't intend the above to be exhaustive.) Making this a little more complete: - patch/bug release 2.3.3? (fix for D tools) - Node class patch (switch to __slots__) - Integration of stubprocess.py - release 2.4? - then, Python3 and Toolchain? OK, step 1's complete. Next up, __slots__ and stubprocess. Both of those will need more testing than usual. We could do a checkpoint release, or just announce on the user list when they're in. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
On 25.08.2014 20:54, Bill Deegan wrote: Looks like some of the memory clean up may have broken interactive mode. Take a look at: http://scons.tigris.org/issues/show_bug.cgi?id=2971 Yeah, I noticed. I'll contact the user and try to find out what goes wrong, hopefully resulting in a MWE and additional testcase(s). Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] catching up
Anatoly, please find a few comments below. On 25.08.2014 10:51, anatoly techtonik wrote: On Mon, Aug 25, 2014 at 1:52 AM, Dirk Bächle tshor...@gmx.de wrote: On 24.08.2014 21:02, anatoly techtonik wrote: On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: Then I'd like to revisit Mercurial workflow, because we need to clarify how to rebase pull requests. I would really like to understand why we need a rebase for pull requests in the first place. 1. To get clean linear history, which humans can browse without advanced graphical tools. Well, unfortunately history isn't always linear when you're working in parallel with several people. I don't mind if a developer locally squashes his commits or uses the MQ extension to reorganize his current bug branch/bookmark for better readability. But once his commits are pushed to his fork at bitbucket (not even the master), history should be regarded frozen. So I wouldn't vote for making rebases mandatory for any pull request...or even go as far as refusing non-fast-forward pushes on the server (current master). I just don't think this is the way to go, especially if we're after getting more contributors into the project. We have to be open towards newcomers, for which we should offer a very basic workflow (like we have described now in the Wiki). And experienced developers can feel free to fiddle with their commits while preparing their next pull request. All together, we're already in a very good state...and for those long-termed dev branches it's just up to a few people to finally detect and embrace the MQ and rebase extensions of Mercurial. 2. To resolve conflicts. Just for example https://bitbucket.org/scons/scons/pull-request/155/adds-a-test-case-demonstrating-that-issue/diff#Ltest/SWIG/include-directive.pyT59 A conflict has to get resolved, for rebase as well as for a simple merge. I don't see how a rebase is more helpful in this situation. 2.1 To update CHANGES.txt after other PR did this 3. Addressing review comments Once a change was committed, I can only add another commit to amend things. I don't see how a (local) rebase can help here...as written above, I exclude remote rebasing from my considerations. 4. Testing PR on top of other fixes 5. Squashing commits 6. Moving stuff to a different branch There are other options available, like MQ again, to accomplish these. I still don't see the urgent need to have rebasing...sorry. I guess for every reference you show me, I can come up with a page against git's rebase, like the following: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html http://rlc.vlinder.ca/blog/2013/03/flawed-ways-of-working-git-rebase/ http://jhw.dreamwidth.org/1868.html , but an URL fight is definitely not what I'm after. For me, it somehow shows that this is a highly opinionated discussion...further meaning that there are no clear facts to decide for one side or the other. So we probably can't lose if we switch (except the efforts for another migration), but we also don't lose a lot if the merge workflows stay as they are now. 7. Finally a reason to know Mercurial better As I said, a highly opinionated discussion... ;) I see these two features - stubprocess.py and __slots__ as branches (ideally all feature should be optional, so that you can turn off them, for example for porting code to Lua). Lua, what? Where does that suddenly come from? I don't see any porting activities to other languages on the roadmap, and I don't remember any discussions about it either. So why should we give our current development a direction based on imaginary features? Sorry, it is just a bit of forward thinking. The same stuff that made me mad when I saw the Docbook toolchain committed. Last time I tried to clone SCons over SSH it took 20 minutes and I knew it will happen. As for Lua. Right now there are better systems than SCons in some aspects, for example http://industriousone.com/premake in Lua which is absent from http://scons.org/wiki/SconsVsOtherBuildTools and http://martine.github.io/ninja/ used by Chromium guys, who I believe ditched SCons at some point even though they've built a Hammer harness on top of it. The reason why such tools appear is that the old code base becomes too overcomplicated for new features to add, and I am afraid that people primarily abandon projects for this reason. Okay, but that's your own perception. Do you know of any projects (names, please) that have ditched SCons because the code base was too complex? When I google for scons slow, I seem to get more project-related hits than for scons complicated or scons complex. And for projects like Ardour, Dolfin or Chromium, speed was the main reason to switch. I'm not trying to toss your concerns aside here, but I would like to take care of the highest prio items first...and highest prio gets somewhat dictated by what most users want, right? I want to be able to
Re: [Scons-dev] catching up
Just a project I know of that moved to cmake from scons. Freeorion: http://www.freeorion.org/index.php/Main_Page -Original Message- From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Dirk Bächle Sent: Monday, August 25, 2014 3:43 PM To: SCons developer list Subject: Re: [Scons-dev] catching up Anatoly, please find a few comments below. On 25.08.2014 10:51, anatoly techtonik wrote: On Mon, Aug 25, 2014 at 1:52 AM, Dirk Bächle tshor...@gmx.de wrote: On 24.08.2014 21:02, anatoly techtonik wrote: On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: Then I'd like to revisit Mercurial workflow, because we need to clarify how to rebase pull requests. I would really like to understand why we need a rebase for pull requests in the first place. 1. To get clean linear history, which humans can browse without advanced graphical tools. Well, unfortunately history isn't always linear when you're working in parallel with several people. I don't mind if a developer locally squashes his commits or uses the MQ extension to reorganize his current bug branch/bookmark for better readability. But once his commits are pushed to his fork at bitbucket (not even the master), history should be regarded frozen. So I wouldn't vote for making rebases mandatory for any pull request...or even go as far as refusing non-fast-forward pushes on the server (current master). I just don't think this is the way to go, especially if we're after getting more contributors into the project. We have to be open towards newcomers, for which we should offer a very basic workflow (like we have described now in the Wiki). And experienced developers can feel free to fiddle with their commits while preparing their next pull request. All together, we're already in a very good state...and for those long-termed dev branches it's just up to a few people to finally detect and embrace the MQ and rebase extensions of Mercurial. 2. To resolve conflicts. Just for example https://bitbucket.org/scons/scons/pull-request/155/adds-a-test-case-de monstrating-that-issue/diff#Ltest/SWIG/include-directive.pyT59 A conflict has to get resolved, for rebase as well as for a simple merge. I don't see how a rebase is more helpful in this situation. 2.1 To update CHANGES.txt after other PR did this 3. Addressing review comments Once a change was committed, I can only add another commit to amend things. I don't see how a (local) rebase can help here...as written above, I exclude remote rebasing from my considerations. 4. Testing PR on top of other fixes 5. Squashing commits 6. Moving stuff to a different branch There are other options available, like MQ again, to accomplish these. I still don't see the urgent need to have rebasing...sorry. I guess for every reference you show me, I can come up with a page against git's rebase, like the following: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html http://rlc.vlinder.ca/blog/2013/03/flawed-ways-of-working-git-rebase/ http://jhw.dreamwidth.org/1868.html , but an URL fight is definitely not what I'm after. For me, it somehow shows that this is a highly opinionated discussion...further meaning that there are no clear facts to decide for one side or the other. So we probably can't lose if we switch (except the efforts for another migration), but we also don't lose a lot if the merge workflows stay as they are now. 7. Finally a reason to know Mercurial better As I said, a highly opinionated discussion... ;) I see these two features - stubprocess.py and __slots__ as branches (ideally all feature should be optional, so that you can turn off them, for example for porting code to Lua). Lua, what? Where does that suddenly come from? I don't see any porting activities to other languages on the roadmap, and I don't remember any discussions about it either. So why should we give our current development a direction based on imaginary features? Sorry, it is just a bit of forward thinking. The same stuff that made me mad when I saw the Docbook toolchain committed. Last time I tried to clone SCons over SSH it took 20 minutes and I knew it will happen. As for Lua. Right now there are better systems than SCons in some aspects, for example http://industriousone.com/premake in Lua which is absent from http://scons.org/wiki/SconsVsOtherBuildTools and http://martine.github.io/ninja/ used by Chromium guys, who I believe ditched SCons at some point even though they've built a Hammer harness on top of it. The reason why such tools appear is that the old code base becomes too overcomplicated for new features to add, and I am afraid that people primarily abandon projects for this reason. Okay, but that's your own perception. Do you know of any projects (names, please) that have ditched SCons because the code base was too complex? When I google for scons slow, I seem to get more
Re: [Scons-dev] catching up
On Mon, Aug 25, 2014 at 4:58 PM, Kenny, Jason L jason.l.ke...@intel.com wrote: They used SCons as a bunch of env.Execute() statements. They basically did the build during the read phase Eww! -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
