[Scons-dev] SCons default branch open for python 2.7/3.x work. Please submit pull requests

[Bill Deegan]

All,

Here's what I propose.
1. Merge scons_python3 down to default.  It's o.k if it's broken for a bit.
We can always do bug fixes out of rel_2.5.0 branch if needed and merge
those down.
2. I'm o.k. with many tests failing when merged down to default. Python 2/3
is a major project and move forward for SCons.  As far as fixing those
embedded code strings, I'd like to see a pull request per fix (so it's easy
to review).   If we're talking about moving them to the new test fixtures
(see: "working with fixtures" in
https://bitbucket.org/scons/scons/wiki/DeveloperGuide/TestingMethodology),
I'm all for that.

2+.  I'd say we should add some thing to TestSCons.py to return which
version of python is being used and allow skipping tests the same way we do
for different platforms for the time being.

Once it's merged down to default, ideally the priority would initially be
to get all the tests passing on python 2.7.  Then python3 compat.

I know this is a departure from past workflows but I'm not sure how else to
do this in a way that would enable moving fairly fast.

Once we get to all tests working on python 2 & 3, then I'd like to shift
back to a slower more deliberate process that's been our norm.
I'm hoping this can be achieved in 2-3 months? (Does that seem realistic)

During that time py2/3 pull requests will get priority, non py2/3 patches
will be secondary unless there's a significant regression in 2.5.0 and/or
support for new MSVS/VC or other "critical" toolset.

If you make fairly small pull requests I'll make commitment to merge them
quickly. (Assuming I'm not off the grid, which is a rarity).

Thoughts on above most welcome.

Thanks,
Bill
Co-Manager SCons project.

On Sun, Apr 10, 2016 at 8:02 AM, William Blevins <wblevins001 at gmail.com>
wrote:

> Two Questions,
>
> 1. Are we working out of scons__python3 or merging scons__python3 and
> working there?
>
> 2. Many of the failing tests are from embedded code blocks in the tests
> which futurize and six didn't update automatically. Should the update
> process here be "make the embedded code its own file when reasonably
> possible" or "just make minimal updates for now"?
>
> V/R,
> William
>
>
>
> On Sun, Apr 10, 2016 at 12:25 AM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> All,
>>
>> It's (finally) that time.
>> Please submit small pull requests if possible, rather than one with a
>> million files/changes.
>> (AIU) Bitbucket doesn't handle huge pull requests very well.
>>
>> I'll be setting up a python 3 buildslave.
>>
>> We'll be using futurize (If I remember correctly), how do we want to
>> handle getting that package (and any requirement's it pulls in) installed?
>> Embed? Add to setup.py? Other
>>
>> -Bill
>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> _______________________________________________
> 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/20160410/fad8fb82/attachment-0001.html>