[OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>>> 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel