Patchwork 2.0 ready for takeoff?

Stephen Finucane stephen at that.guru
Fri May 5 05:16:11 AEST 2017


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 <dja at axtens.net> 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
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork



More information about the Patchwork mailing list