Our fork of the Freedesktop fork is currently running on Python 2.7 [1]. Upstream patchwork-fdo has recently been updated all the way to Django 2.2 LTS [2], which is Python 3 (only). The patches we have on top of the Freedesktop fork need to be investigated to see whether they can be rebased on top of latest patchwork-fdo. Or whether the funtionality our patches added can be upstreamed or is already present in the patchwork-fdo repo. FWIW, things have deviated too much from the original ozlabs patchwork, so any effort to move to "mainline" patchwork is probably fruitless and should be discouraged. [1] http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/tree/tox.ini [2] https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/commit/bb22eebae419e27be0f617f2e5ebb8bf6af86bfc
The "shortest" path, might be updating to Django 1.11 LTS, which does have Python 3 support. Looking at our fork, I have not yet found what commit from patchwork-fdo we started with.
Created attachment 4608 [details] local commit of patchwork
@Randy I rebased patchwork to lastest upstream patchwork-fdo, after rebase, patchwork instance can startup success, I do below simple operation: 1. create projects --- seems work well 2. load one series for one of projects ---work well 3. view patch.html 4. view series.html for step3 and step4, some of the function we add locally not work maybe since there is too much gap, the layout of web is changed. And as I see, most of the work need to work with css/js/html, but unfortunately, I don't have too much knowledge about frontend. So I think it is better to assign this to who is good at this, in this way, it is possible to rebase current patchwork to lastest upstream patchwork-fdo. I have attached the local_commit for refer.
Paul, Would you be able to take over this defect from here or could you help Sandy with it?
I did some review of patchwork-fdo. We forked after this commit: https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/commit/d8a74c393d77125bfd308e491be9a82b6b6f27d0 Which correlates to this commit in yp patchwork: http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/commit/?id=d8a74c393d77125bfd308e491be9a82b6b6f27d0 The next commit in yp patchwork has an equivalent commit in patchwork-fdo. http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/commit/?id=2ac92336dcca550fe53aa8dd06793d8456cf7191 https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/commit/831ebd7c670d6383c9233335c4084b481d87e1b0 The key commits in patchwork-fdo that bump the Django version are: - Django 2.0: https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/commit/6f7389f9b134e388fb4647264d5f9d3e2aa0b54e - Django 2.1: https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/commit/732e033b1ea8c59408430b034f955ca10db72ee9 - Django 2.2: https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/-/commit/bb22eebae419e27be0f617f2e5ebb8bf6af86bfc
We have ~50 commits on top of the fork. These will have to be gone through one by one to see whether the equivalent is already upstream, whether it is functionality upstream would accept, or whether it is a feature specific to us that we cannot live without and we need to carry the technical debt. As an example of likely upstream friendly change (which we would have trouble living without): models.py: Mark patches as superseded when receiving a new revision http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/commit/?id=6bc63d14d298ad97cf1ea3c9439c1fbad081878b Upstream patchwork-fdo has many many commits on top of where we forked. It appears that it will be much less work to try to rebase our changes on top of their tree than the other way around. But upstreaming our changes would be even better.
Upstream commit count since we forked: git rev-list d8a74c39..HEAD | wc -l 166 Yocto commit count since we forked: git rev-list 855a5db..HEAD | wc -l 45 since we forked:
Correction: Yocto commit count since we forked: git rev-list d8a74c39..HEAD | wc -l 49
We moved to upstream patchwork