<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 25, 2016 at 3:49 PM, Markus Neteler <span dir="ltr"><<a target="_blank" href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-a3s gmail-aXjCH gmail-m15762e5461fa7be1" id="gmail-:ns">when doing each job in its own mapset and reintegrate it in a single<br>
target mapset as if able to process then in parallel in one mapset by<br>
simply specifying the respective region to the command of interest.<br>
Yes, different from the current paradigm and not for G7.<br></div></blockquote><div><br>I think, we can accommodate this behavior in G7. In fact, each command can run with a separate region even now. It can set it on its own, take it from GRASS_REGION or WIND_OVERRIDE. But if you are talking about automatic patching, that's of course different.<br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-a3s gmail-aXjCH gmail-m15762e5461fa7be1" id="gmail-:ns">
<br>
But my original comment was targeted at the increasing number of<br>
module parameters and how to handle that (with some new HPC related<br>
idea as an example).</div></blockquote></div><br>I think we need to talk about specific use cases and decide based on that. For some, Advanced or HPC tab might be enough. Some others might be better addressed by a specific global options like what Soeren just suggested (in the style of --overwrite).<br></div></div>