[Scons-dev] catching up

[anatoly techtonik]

On Sun, Aug 24, 2014 at 9:09 PM, Gary Oberbrunner <garyo at oberbrunner.com> wrote:
> On Sun, Aug 17, 2014 at 5:36 PM, Dirk Bächle <tshortik at 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.

For testing we need to make buildbots green before making any changes,
so that regression testing becomes possible. Merging this:
https://bitbucket.org/scons/scons/pull-request/178/taprunner-02-remove-unused-import-that
will help fix to this buildbot
http://buildbot.scons.org/builders/ubuntu-python-2.6/builds/118/steps/shell/logs/stdio

Then I'd like to revisit Mercurial workflow, because we need to clarify how to
rebase pull requests. I can also answer other questions about workflow,
because Git approach is pretty reasonable, and without some Mercurial
candies that are absent in Git it can be hard to stick to it. Our benefit in
sticking to Mercurial is to avoid loosing history.

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).
But first they need some concise SCons Enhancement page, linked from
http://scons.org/wiki/Roadmap so that users can understand what do they
need testing. Right now there is no info about stubprocess.by (and other
entries should probably by moved to some 'Stale' status).


I am not sure we need to do checkpoint releases anymore. It is already
possible to run SCons from source, so hg clone and run should be enough
to test.

-- 
anatoly t.