[Piglit] Port piglit framework to python3, round 2

[Dylan Baker]

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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20150313/72477031/attachment.sig>