>>> What would your preferred workflow be? Please list the exact series of >>> steps for it. >> So to summarize, based on the current workflow: >> 1. Be able to send mails (and change status) from within patchwork, e.g. >> how you can do it in trac, just that it gets send out to the ML and the >> author instead >> of being just hidden in some UI. > Maybe you could suggest that to the patchwork author. I guess so.
> >> 2. Download a whole set of the patches (e.g. one patch series) >> without having to do it for all patches indivdually (e.g. like Github >> let's you download >> a whole pull-request as a single patchfile). I'm fine with it even not >> keeping track what >> patches belong to which series, but just having e.g. a page with >> checkboxes where >> I can tick patches and some where on the bottom click "download series >> as .patch". > Just select a bunch of patches, put in a name at the bottom of the page > and click "Create bundle". You can download that bundle as .mbox Yeah using bundles can sort of do that, but it can get cumbersome quickly as well. You first have to select the patches and create a new bundle, then click on bundles, and click download for the new bundle which I guess is somewhat reasonable. However once you are done, you have to either - remove accepted patches from the bundle or kill the whole bundle and start over next time, because the bundle always gets you all patches in it, including the ones accepted or rejected. I guess again, its a start but needs some improvements to feel really convenient. Maybe suggesting a second button to the author "download patches needing action" or so, would do it. > >> 4. Ideally have some sort of integration with a bugtracker. > What kind of integration and for what purpose? It's mainly having some tool that is integrated, i.e., uses same credentials and maybe even the possibility to close related tickets just by accepting the patches. Using entirely different tools just feels a bit unnecessary. I do not consider that to be an essential issue really, more like a nice to have which you get to like when working with more integrated environments. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
