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