bump
On Thu, Mar 05, 2015 at 02:04:00PM -0800, Dylan Baker wrote: > This is a proposal for another go at moving to python3 for the > framework. Due to the amount of work that's gone into piglit over the > last few months and years the codebase is very modern, and the > transition is pretty straightforward, the only major change is the > bytes/unicode/str conversion, which isn't that hard for us since we've > already relied on the unicode class for a number of our string > interfaces. > > So why python3, and why now? > > The first argument for python3 is features. Feature work is ongoing in > python3, while python2 is in long term maintenance mode, and there are > features landing in python3 that will either allow us to simplify the > piglit code, or to enable useful features with minimal effort. Patch 2 > provides a sane, portable timeout implementation for piglit to > demonstrate this. > > The second argument I can offer is that linux distributions are starting > to make the transition to python3 as their default python version. Arch > and Fedora have already made this jump. For windows and OSX the python > foundation provides pre compiled binaries. > > But what about platforms that don't have python3.3+ available? > > Well, the goal of recently landed changes to the generators was to > hybridize the generators to work under either python2.7 or python 3.3+, > with the same code base, and this series doesn't change that, nor do I > have any plans to do so while there are still python2 consumers. The > goal being that tests (including generated tests) should be backportable > to the python2 branch without any changes being necessary. > > The idea then is that directly before landing this code a python2 branch > of piglit would be forked and pushed to the upstream repository. Those > that need python2 would be able to use the python2 branch for testing, > while upstream development would continue on master, which used python3. > > Any changes that were strictly necessary to keep the python2 branch > working with the python3 branch would be backported, presumably by > myself, but the goal would be to minimize the number of python changes > backported. The one drawback here would be that if the summary format of > master (python3) changed it's unlikely that would be backported to > python2. Master would still be able to understand python2 generated > results, but not vice versa. > > So, to sum up: > > 1) branch a python2 branch, tests should be able to cherry-picked/merged > cleanly > 2) python changes necessary to keep the python2 branch running would be > backported > 3) When python2 is no longer necessary for anyone the branch could be > dropped. >
signature.asc
Description: Digital signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
