That sounds fine to me. On Sun, Apr 10, 2016 at 7:56 PM, Bill Deegan <[email protected]> wrote:
> 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 > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
