[Scons-dev] catching up

[Dirk Bächle]

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 <tshortik at gmx.de> wrote:
>> On 24.08.2014 21:02, anatoly techtonik wrote:
>>> On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner <garyo at 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 "rebase"s 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 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.
The oncoming changes don't affect the architecture and design of SCons 
at all. So you should be able to visualize whatever parts of SCons you 
want to analyze, in parallel and completely decoupled from the current 
development.

Best regards,

Dirk