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
[email protected]
https://lists.ozlabs.org/listinfo/patchwork
_______________________________________________
Patchwork mailing list
[email protected]
https://lists.ozlabs.org/listinfo/patchwork
