Patch tagging/classification

Ruslan Kuprieiev kupruser at gmail.com
Tue Feb 9 05:08:58 AEDT 2016



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,
>



More information about the Patchwork mailing list