Patch tagging/classification

Tue Feb 9 08:34:31 AEDT 2016

Hi Stephen,

On 02/08/2016 08:45 PM, Finucane, Stephen wrote:
> On 08 Feb 20:08, Ruslan Kuprieiev wrote:
>> 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.
> Are you trying this for development or production? If the former, have
> you tried the new developer docs [1]? I have the advantage of
> maintaining the thing, but I was able to get a new dev environment up
> and running in about 10 minutes this way. This will be shorter as soon
> as I figure out how to use Docker Compose correctly :)

I'm trying it for development, I'm not ready to suggest installing it to
our production server just yet. I didn't try new developer docs yet,
thank you for the link, I'll try it shortly.

> If the latter, I'd suggest looking at an existing project to do this
> for you. I used the ansible-django-stack project [2] recently to do
> almost everything for me. I'm also investigating packaging patchwork
> for a few distros but we've some higher priority things on the roadmap
> first. I would be more than happy to provide guidance on how to use
> this tool.

Didn't know about ansible-django-stack too. I'll try it too, thanks.

>> 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.
> Yup - I hear ya. It took me a few days way back when to realise I
> didn't need to set up my own mailing list to get working on pathwork.
> If you see any issues with the above documentation, however, then
> patches and/or questions will be gratefully received.

Sure, will be more than happy to contribute =).

>>> Installing patchwork is quite involved though:
>>>    - mail integration (how patchwork receives emails, there are many ways
>>>      to do that)
> Damien - this is the one that always catches me out :( Would it be
> possible to turn your hand to documenting your recommendations here at
> some point?
>
>>>    - 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 =)
> Check out the docs above - it's not all wrapped up in a VM/container
> (that's coming) but using virtualenvs etc. is par for course as part of
> the development workflow for either patchwork or the freedesktop fork.

Thank you, I'll take a look at those.

>
> Stephen
>
> [1] https://patchwork.readthedocs.org/en/latest/development/
> [2] https://github.com/jcalazan/ansible-django-stack
>
>> 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 at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/patchwork