On 02/08/2016 07:46 PM, Damien Lespiau wrote:
On Mon, Feb 08, 2016 at 05:19:37PM +0200, Ruslan Kuprieiev wrote:
It looks fantastic, and it is exactly what I've been looking for for a long
time now.
Why aren't these features merged into base patchwork yet?
I wanted to make some fairly big design decisions that didn't resonate
well with where other people wanted patchwork to go: bootstrap, REST API
(instead of XML-RPC), series, test results API and result emails sent
from patchwork, git pw (instead of pwclient), use of the REST API from
the web pages, having dependencies not linked to what distributions
offer, ... So I went off experimenting.
I suspect it'll be hard and time consuming to reconcile the two
branches.
Oh, I see.
How hard can it be to use your patchwork version for another project?
I'm participating in CRIU[1] project and we would love to try your patchwork
mod.
A note of caution, the two active patchwork branches have different DB
schemas, so choosing one branch means it'll be hard to migrate to the
other one.
I'm not sure if you already have a deployed patchwork instance. If so
and if you're using Jeremy Kerr's patchwork, both Patchwork branches are
a fast forward and support DB migrations.
I tried spending a day on installing and running vanilla patchwork but
didn't find instructions very accurate and informative and the overall
process was a total failure.
I don't have much experience with DBs/Django and related things, so
as for a newbie like me it is quite hard and frustrating to install it. I
would much rather prefer something like what a webmin does -- you
just download it, folow few quick steps and voilla! -- you have it ready
on a particular port. I wish patchwork was that easy to get up and
running.
Installing patchwork is quite involved though:
- mail integration (how patchwork receives emails, there are many ways
to do that)
- Have a DB around
- Web frontend to Django app
- git hook on the repos to mark the patches Accepted
Hook which a contributor(i.e. who is sending a patch with git send email)
should use or an "internal" git hook for a patchwork itself?
Do you oblige patch sender to provide any additional information(i.e.
commit id, change-id or what not)?
- There's also a cron job (that I'd like to replace with a celery
task)
As mentioned before, Freedesktop's patchwork has a somewhat strong
opinion on distribution dependencies. It favours deploying patchwork in
an isolated, sateless, WM/container (or at least in a virtualenv) with a
tight control on the versions of those dependencies (as opposed to
relying on the distribution packages). People have voiced concerns about
this, but I find it rather freeing.
I totally support this opinion. From a user standpoint, that doesn't
want to get into
deep fiddling with packages and configurations of DBs and Django, I
would prefer
to just download, unpack, do 2-3 additional trivial steps and have my
own patchwork
ready to serve my mailing list =)
Do you have your patchwork version in a easy-to-deploy form? If you do,
would mind
sharing it? I would love to try it out.
HTH,
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
