On Tue, 2017-05-02 at 11:00 +0100, Stephen Finucane wrote: > On Mon, 2017-05-01 at 21:19 +1000, Daniel Axtens wrote: > > Daniel Axtens <[email protected]> writes: > > > > > Hi Stephen, > > > > > > Apologies on my patchwork-silence; I've recently moved from IBM > > > to Canonical so I've been a bit flat-out. > > It's all good :) I'm just eager to wrap up 2.0 before the summer > kicks in in earnest, hence the push. > > > > I haven't tested the patches for support for distro-package > > > Xenial, so I'd like to do that, and also do some Debian (and > > > maybe CentOS?) tests. I am hoping to get that done in the next > > > couple of days. > > > > OK, Xenial works. If anyone wants to test against the API, feel > > free to use py2 or py3.patchwork.dja.id.au; please let me know how > > it goes. > > Yup, I went through the deployment installation guide last night and > updated it to use Xenial (vs. Vivid) and system packages (vs. PyPi > packages). It worked mostly without issue, my own lack of experience > with nginx/uWSGI and some Python 2/3 issues aside. The patches are > up if you want to take a shot at them. > > BTW, I assume you used your saltstack formula [1] to deploy the two > instances above? I wonder if you'd like to include a link to that in > the documentation (or even move it into 'getpatchwork', if that would > aid discovery). > > > I will try to do some debian/fedora/centos tests going eventually. > > I'm going to give Debian a spin tonight. I'll probably focus on > Stretch as Jessie uses django-rest-framework 2.x. > > I can't imagine too many people deploy things on Fedora, given it's > near-bleeding edge nature and lack of support (ditto for non-LTS > Ubuntu), and CentOS/RHEL look unlikely, given the sorry state of > Django in EPEL [2]. I think we can and should ignore both and assume > generic PyPi-based installations for those users. > > > Regards, > > Daniel > > > > > > > > I also think we should do an RC after we land all the features; > > > that'll give people a bit of warning and an impetus to test (as > > > well as definite target to test, rather than the somewhat more > > > nebulous 'master'). > > Yup, you suggested that before and it sounds like a good call. I > don't think any of the issues I listed are blockers for an RC, and > I'm not aware of any others. Unless there are objections, I can tag > an RC on Friday. > > Stephen
I've gone ahead and tagged rc1, as seen on GitHub [1]. Feel free to test away. Anyone have any preferences on how long we should wait before making moves towards an actual release? Stephen [1] https://github.com/getpatchwork/patchwork/releases/tag/v2.0.0-rc1 > > > Regards, > > > Daniel > > [1] https://github.com/dlax/patchwork-formula > > [2] EPEL only provides Django 1.6 with backported security fixes. > It's not possible to update this without breaking the ReviewBoard > package, which supports Django 1.6 only at the moment due to the > custom migrations framework it provides. In addition, it seems the > django-rest-framework and django-filters libraries are not packages > at all. While Patchwork can work with the Django 1.6 and the REST > Framework can be disabled, I don't really want to encourage this kind > of deployment. > _______________________________________________ > Patchwork mailing list > [email protected] > https://lists.ozlabs.org/listinfo/patchwork _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
