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