Re: Patch tagging/classification
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 sharin
Re: Patch tagging/classification
On 02/08/2016 08:50 PM, Damien Lespiau wrote: On Mon, Feb 08, 2016 at 08:08:58PM +0200, Ruslan Kuprieiev wrote: 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. Unfortunately, I don't have anything to share. Right now, each admin has to figure out how patchwork can fit in the existing infrastructure (and there are quite a few combinations). I myself use fabric (http://www.fabfile.org/) to automate the deployment of patchwork, but that only works with a manual first installation. I can see how a better story for both the installation and updates of patchwork is needed, as well as a few supported ways to hook an existing mailing-list that isn't necessarily on the same host as patchwork. I think it should be fairly straightforward to make a docker image with PostgreSQL, django and patchwork. To feed emails to patchwork, I'd create a new REST entry point that would accept emails given the proper credentials. Basically the same code as today but decoupling patchwork from the host the mailing-list is hosted on. Then, mail delivery to patchwork could be hooked to anything: local delivery (/etc/aliases and local(8) as documented today) or a script feeding emails from any source (eg. fetchmail + procmail). I've added it to the TODO list but, time is scarce. In my hand-made solution I used smtp and pop3 python modules to fetch mail for a configured gmail account that is subscribed to a certain mailing list. Fetching and sending was quite easy and worked well, even considering gmail restriction on allowed frequency of checking email(once in 5-8 minutes was fine). So yeah, ability to use both mailing list and arbitrary email subscribed to that mailing list would be quite handy, especially for development, allowing people to tryout patchwork somewhere safe and not pollute production server just yet. Docker file with a list of needed packages and commands would be great. I'll try to set up patchwork once again by the end of this week and will try to provide some feedback or even some changes to docs to make things clear for newbies like myself. Thanks, Ruslan ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
Damien, All,
On 2016-02-08 15:02 +, Damien Lespiau spake thusly:
[--SNIP--]
> I think I'd like to see a tool to wrap git
> send-email, that would ensure a more deterministic way of sending
> patches and updates after review see:
>
> https://github.com/dlespiau/patchwork/issues/81
Not sure that would fit your needs (at least not as described in the PR
you linked above), but I have a git wrapper around send-email +
request-pull:
https://github.com/yann-morin-1998/git-wrappers/blob/master/git-send-pull-request
It's basically:
git format-patch BASE..HEAD
git request-pull BASE..HEAD >msg
# some tweaking of msg
${EDITOR} msg
git send-email msg *.patch
with a little bit of sugar: options to control who is in to, cc, bcc,
whether cover-letter is to-ed, cc-ed or bcc-ed to patch authors, whether
to hint patchwork to ignore cover-letter and/or patches, set the version
of the series, add a '[tag]' suffix (e.g. RFC) and so on...
Mails would be sent as (N patches, version M, RFC suffix):
[PATCH 0/N vM RFC] bla bla bla (branch BRANCH-NAME)
+- [PATCH 1/N vM RFC] bla bla foo
+- [PATCH 2/N vM RFC] bla bla bar
...
From your exposed needs, I can see '--in-reply-to' to be missing, but
that can probably be added quite easily. I'm not sure what you call a
'series id', though, but if you refer to a branch name, it's already
there.
Comments most welcome, of course. ;-)
BTW, there's also git-pwc in that repository, a simple dialog-based
pwclient-based frontend to select and apply patches:
https://github.com/yann-morin-1998/git-wrappers/blob/master/git-pwc
(Warning: written for my personal use, might be rough on the edges, won't
be big and professional like... you know the tune! ;-) ).
Regards,
Yann E. MORIN.
--
.-..--..
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `.---: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. |
'--^---^--^'
___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH 00/19] Add latest UI rework changes
On 03 Feb 21:31, Stephen Finucane wrote: > Damien has some really nice work done on the freedesktop instance of > patchwork - so nice, in fact, that I used this instance for screenshots > included in the FOSDEM talk. Take the changes that are useful for > upstream and rebase them. The remaining changes, mostly centered around > series support, can be applied once that feature and related features > are complete. Merged this entire series, given that it's purely cosmetic. We can address any issues folks might have in follow up changes. Stephen ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH 1/2] wsgi: Move wsgi file to expected location
On 05 Feb 17:35, Stephen Finucane wrote: > Django places a wsgi.py file in the root of each application's > directory. Do this, adding a symlink to preserve existing > operation for users. > > Signed-off-by: Stephen Finucane Merged. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
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 :) 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. > 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. > >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. 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@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/patchwork _
Re: [PATCH 2/2] requirements: Use PostgreSQL in production
On 05 Feb 17:35, Stephen Finucane wrote: > The example "production" settings expect a PostgreSQL database backend, > yet the requirements file for the same scenario install MySQL > dependencies. Correct this mismatch. > > Signed-off-by: Stephen Finucane Merged. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH 2/2] xmlrpc: Treat negative max_count as meaning "return last N results"
On 05 Feb 17:21, Stephen Finucane wrote: > From: Adam Jackson > > This is most useful when listing patches, as it lets you get the most > recent results instead of the oldest. > > v2: Resolve "Negative indexing is not supported." issue and include > unit tests to ensure this doesn't regress. Bump API version to > 1.2 > > Signed-off-by: Adam Jackson > Signed-off-by: Stephen Finucane Merged. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: [PATCH 1/2] py3: Ensure map is wrapped in list
On 05 Feb 17:21, Stephen Finucane wrote: > The map function doesn't return a list in Python 3, which means it > can't be used like one. Many of these issues were previously resolved > but there were some uncovered code paths. Resolve these, adding tests > to ensure it doesn't regress. > > In addition, change what's serialized and returned. Instead of > returning a subset of the serialized values, only serialize a subset > of the original values. This means n items are serialized instead of > max. > > Signed-off-by: Stephen Finucane Merged. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
On Mon, Feb 08, 2016 at 08:08:58PM +0200, Ruslan Kuprieiev wrote: > >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. Unfortunately, I don't have anything to share. Right now, each admin has to figure out how patchwork can fit in the existing infrastructure (and there are quite a few combinations). I myself use fabric (http://www.fabfile.org/) to automate the deployment of patchwork, but that only works with a manual first installation. I can see how a better story for both the installation and updates of patchwork is needed, as well as a few supported ways to hook an existing mailing-list that isn't necessarily on the same host as patchwork. I think it should be fairly straightforward to make a docker image with PostgreSQL, django and patchwork. To feed emails to patchwork, I'd create a new REST entry point that would accept emails given the proper credentials. Basically the same code as today but decoupling patchwork from the host the mailing-list is hosted on. Then, mail delivery to patchwork could be hooked to anything: local delivery (/etc/aliases and local(8) as documented today) or a script feeding emails from any source (eg. fetchmail + procmail). I've added it to the TODO list but, time is scarce. -- Damien ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
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
Re: Patch tagging/classification
On Mon, Feb 08, 2016 at 04:18:53PM +0100, Thomas Petazzoni wrote: > I think it's not a big deal if patchwork sometimes doesn't recognize a > new version of a series as being a new version, and leaves it to the > project admins to mark the old version of the series as superseded > manually. > > However, it is in my opinion much less acceptable to see patchwork > losing some patches. I'd rather have too much patches in patchwork that > I need to triage/classify/update rather than missing some contributions. Agreed on both points. We did think about being able to edit series/revision when the parsing goes wrong, but, to be honest, that's not high on the priority list. I only know about a handful of bugs that will lead to losing a patch, so declaring the series support somewhat ready may not be that far away. -- Damien ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
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. > 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. 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 - 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. HTH, -- Damien ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
On 02/08/2016 05:02 PM, Damien Lespiau wrote: On Mon, Feb 08, 2016 at 04:39:15PM +0200, Ruslan Kuprieiev wrote: Hi Damien, That looks great! Is it a pure pwclient you are using? This is a different version of patchwork that I maintain for our own use (I'm part of the i915 kernel team at Intel). That version is deployed on https://patchwork.freedesktop.org/. https://github.com/dlespiau/patchwork The series support is done when emails are parsed by patchwork, reconstructing email threads and creating series/revisions/patches objects instead of merely patches objects. An interesting point is that series objects aggregate the initial submission, but also subsequent updates. A bit more details on what is supported: http://patchwork-freedesktop.readthedocs.org/en/latest/manual.html#submitting-patches Now, I can't stress enough that I still need to iron out some corner cases. There also are cases where it's ambiguous what the sender is trying to do. Parsing the intention of the submitter is hard, people will do the strangest things. I think I'd like to see a tool to wrap git send-email, that would ensure a more deterministic way of sending patches and updates after review see: https://github.com/dlespiau/patchwork/issues/81 That said, we've been using the series support for a few months already with a CI system that take full series of patches for testing and gives test results back. So it's already somewhat useful, if you don't mind the hiccups too much (which can lead to patchwork losing some patches). 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? 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. Corner cases are fine, I tried writing my own tool for mailing list patch tester some time ago and also did run into a number of corner cases and eventually decided to disable it to find a better solution. [1] https://criu.org/Main_Page Thanks, Ruslan ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
Hello, On Mon, 8 Feb 2016 15:02:36 +, Damien Lespiau wrote: > Now, I can't stress enough that I still need to iron out some corner > cases. There also are cases where it's ambiguous what the sender is > trying to do. Parsing the intention of the submitter is hard, people > will do the strangest things. I think I'd like to see a tool to wrap git > send-email, that would ensure a more deterministic way of sending > patches and updates after review see: > > https://github.com/dlespiau/patchwork/issues/81 > > That said, we've been using the series support for a few months already > with a CI system that take full series of patches for testing and gives > test results back. So it's already somewhat useful, if you don't mind > the hiccups too much (which can lead to patchwork losing some patches). I think it's not a big deal if patchwork sometimes doesn't recognize a new version of a series as being a new version, and leaves it to the project admins to mark the old version of the series as superseded manually. However, it is in my opinion much less acceptable to see patchwork losing some patches. I'd rather have too much patches in patchwork that I need to triage/classify/update rather than missing some contributions. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
On Mon, Feb 08, 2016 at 04:39:15PM +0200, Ruslan Kuprieiev wrote: > Hi Damien, > > That looks great! > Is it a pure pwclient you are using? This is a different version of patchwork that I maintain for our own use (I'm part of the i915 kernel team at Intel). That version is deployed on https://patchwork.freedesktop.org/. https://github.com/dlespiau/patchwork The series support is done when emails are parsed by patchwork, reconstructing email threads and creating series/revisions/patches objects instead of merely patches objects. An interesting point is that series objects aggregate the initial submission, but also subsequent updates. A bit more details on what is supported: http://patchwork-freedesktop.readthedocs.org/en/latest/manual.html#submitting-patches Now, I can't stress enough that I still need to iron out some corner cases. There also are cases where it's ambiguous what the sender is trying to do. Parsing the intention of the submitter is hard, people will do the strangest things. I think I'd like to see a tool to wrap git send-email, that would ensure a more deterministic way of sending patches and updates after review see: https://github.com/dlespiau/patchwork/issues/81 That said, we've been using the series support for a few months already with a CI system that take full series of patches for testing and gives test results back. So it's already somewhat useful, if you don't mind the hiccups too much (which can lead to patchwork losing some patches). -- Damien ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
Hi Damien, That looks great! Is it a pure pwclient you are using? Thanks, Ruslan On 02/08/2016 04:25 PM, Damien Lespiau wrote: On Mon, Feb 08, 2016 at 03:28:26PM +0200, Ruslan Kuprieiev wrote: Hi All, Btw, is patchwork able to group several patches from one patchset? I.e. typical git-send-email structure: [PATCH 00/03] intro |-[PATCH 01/03] first |-[PATCH 02/03] second |-[PATCH 03/03] third I'm asking here, because it might be related to tagging/classification topic. One of the scenarios where it might be handy is using patchwork to automatically test mailing list patches. I have something somewhat working: https://patchwork.freedesktop.org/series/3129/ But it's still not really production quality. ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
On Mon, Feb 08, 2016 at 03:28:26PM +0200, Ruslan Kuprieiev wrote: > Hi All, > > Btw, is patchwork able to group several patches from one patchset? > I.e. typical git-send-email structure: > [PATCH 00/03] intro > |-[PATCH 01/03] first > |-[PATCH 02/03] second > |-[PATCH 03/03] third > I'm asking here, because it might be related to tagging/classification > topic. > One of the scenarios where it might be handy is using patchwork to > automatically test mailing list patches. I have something somewhat working: https://patchwork.freedesktop.org/series/3129/ But it's still not really production quality. -- Damien ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
Hi All, Btw, is patchwork able to group several patches from one patchset? I.e. typical git-send-email structure: [PATCH 00/03] intro |-[PATCH 01/03] first |-[PATCH 02/03] second |-[PATCH 03/03] third I'm asking here, because it might be related to tagging/classification topic. One of the scenarios where it might be handy is using patchwork to automatically test mailing list patches. Thanks, Ruslan On 02/07/2016 05:02 PM, Thomas Petazzoni wrote: Hello, I don't remember if I already suggested this feature, or if it has been suggested in the past already. If that's the case, then sorry for the duplicate. Over at the Buildroot project, we often handle a fairly long queue of patches in our patchwork, currently around 350+ patches. One thing that I'm missing is a way of triaging/tagging the patches, like which ones are for the current release, which ones are clearly for the next release, etc. Each project probably has different tagging/classification needs. Wouldn't it be useful to create a tagging system which allows to associate an arbitrary list of tags to each patch. This could even replace the delegation feature by adding special tags like "delegate:" to delegate the patch to a certain user. This would also have the benefit of allowing the delegation to more than one user, by simply having several "delegate:" tags on the same patch. This of course should come with filters in the web UI, in order to filter patches depending on the tags that they have. Thoughts? Side question: has the patchwork project considered participating to the Google Summer of Code? I believe patchwork is really a good project for GSoC students: it's using a technology that is worth learning, getting into the internals of patchwork is not too complicated, etc. Thomas ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
On Sun, Feb 07, 2016 at 04:02:40PM +0100, Thomas Petazzoni wrote: > Hello, > > I don't remember if I already suggested this feature, or if it has been > suggested in the past already. If that's the case, then sorry for the > duplicate. > > Over at the Buildroot project, we often handle a fairly long queue of > patches in our patchwork, currently around 350+ patches. One thing that > I'm missing is a way of triaging/tagging the patches, like which ones > are for the current release, which ones are clearly for the next > release, etc. Each project probably has different > tagging/classification needs. That idea has been floating around indeed. That's something I want as well. https://github.com/dlespiau/patchwork/issues/36 I'm leaning towards some key/value pair associated with patches and revisions, allowing the key to be null for simple tagging. -- Damien ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: Patch tagging/classification
On 07 Feb 16:02, Thomas Petazzoni wrote: > Hello, > > I don't remember if I already suggested this feature, or if it has been > suggested in the past already. If that's the case, then sorry for the > duplicate. > > Over at the Buildroot project, we often handle a fairly long queue of > patches in our patchwork, currently around 350+ patches. One thing that > I'm missing is a way of triaging/tagging the patches, like which ones > are for the current release, which ones are clearly for the next > release, etc. Each project probably has different > tagging/classification needs. > > Wouldn't it be useful to create a tagging system which allows to > associate an arbitrary list of tags to each patch. This could even > replace the delegation feature by adding special tags like > "delegate:" to delegate the patch to a certain user. This > would also have the benefit of allowing the delegation to more than one > user, by simply having several "delegate:" tags on the same > patch. > > This of course should come with filters in the web UI, in order to > filter patches depending on the tags that they have. > > Thoughts? I like it: it reminds me a little bit of both StackExchange's "tags" system [1] or GitHub's "labels" [2] and should provide a good boost in making patchwork a little more "indexable". I think we should decide which aspects of the above approaches we should take (I'm using the tag nomenclature for now). * Who should be able to create tags: project admins, maintainers, or everyone? * Should the tags be tied to the specific patchwork project or the entire instance? AFAIK the current "tag" implementation (for Acked-by, Reviewed-by tags) is instance-wide, though disableable on a per-project basis. * Is there any value in parsing non-versioning subject prefixes as tags, e.g. extracting 'project' from '[PATCH project]'? This could be a later enhancement. * Should we be case-sensitive, allow spaces etc.? I'm not too sure about replacing the delegate feature, however. While I do see the overlap, I think delegating a patch is a different operation from assigning a tag. For example: a user will likely wish to see patches delegated to them on their homepage. > Side question: has the patchwork project considered participating to > the Google Summer of Code? I believe patchwork is really a good project > for GSoC students: it's using a technology that is worth learning, > getting into the internals of patchwork is not too complicated, etc. I considered it, but I couldn't think of anything meaty enough that people weren't already working on. Perhaps this would be a good start? Cheers, Stephen [1] https://stackoverflow.com/help/tagging [2] https://developer.github.com/v3/issues/labels/ > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > ___ > Patchwork mailing list > Patchwork@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/patchwork ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
