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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
