<html><head></head><body>Sorry Christoph,<br><br>if I made the impression that I was criticizing you.<br><br>It was a general comment. We currently lack a good way to make certain discussions more public, of necessary. If people are temporarily (too) busy they easily don't find the time to follow all gitlab discussions. I experience this myself from time to time. In such cases it would be good if the really important discussions somehow stock light, so that we ensure everybody is heard.<br><br>You were the unlucky person who stepped on someone's [Roberts ;-)] toes, because *we all* failed to have these situations in mind and we don't have a good procedure for this case.<br><br>So, perhaps this questions should first go to Robert... do you have a good suggestion how we should proceed on the future and make sure nobody misses an important discussions/vote?<br><br>Perhaps one last comment... If we'd have a meeting and only very few people explicitly express their opinion, I'm pretty sure we would not couldn't this as a Yes. We'd either start pushing for proper votes, or we postpone this decision.<br><br>Again this is against someone personally, we all as a group need to find ways to organizer our collaboration and these ways need to be reconsidered and discussed from time to time.<br><br>Best<br>Christian<br><br><br><div class="gmail_quote">Am 15. Oktober 2020 23:51:19 MESZ schrieb "Christoph Grüninger" <foss@grueninger.de>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi Christian!<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">For the future, I think Andreas suggestion is good to have a more<br>formal way to decide on a version bump, as a gitlab issue might go<br>unnoticed.<br></blockquote><br>You make it sound, as if I tried to hide my plans in a GitLab MR. I<br>announced it on the mailing list [1]. The mailing list is still the most<br>official way of communication we have (besides developer meetings). I<br>hope we are still able to discuss and decide topics without a meeting.<br><br>Bye<br>Christoph<br><br><br>[1] <a href="https://lists.dune-project.org/pipermail/dune-devel/2020-May/002570.html">https://lists.dune-project.org/pipermail/dune-devel/2020-May/002570.html</a><br><br>> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Best<br>Christian<br><br>On Tue, Sep 29, 2020 at 09:17:28PM +0200, Christoph Grüninger wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Dear fellow Dune core developers,<br><br> in May I merged dune-common#200 [1] which bumped the required CMake<br> version for Dune core modules to 3.13. Roberts want to lower this to<br> CMake 3.10.<br> His rationale is, that Ubuntu 18.04 LTS only ships CMake 3.10.<br><br> As discussed in [1], I (and some others) want 3.12 for better Python<br> detection support and 3.13 for an improved library handling, which will<br> help us to modernize the build system (which we already started).<br><br> To get more arguments and much more opinions, please have a look at [1].<br><br> From the discussion I assume that the following people are in favor of 3.10:<br> Robert<br><br> In favor of 3.13 seem to be:<br> Jö<br> Markus<br> Simon<br> Christoph<br><br> From the following developers I don't have a clear opinion without<br> interpreting too much:<br> Peter<br> Ansgar<br> Andreas</blockquote></blockquote></pre></blockquote></div></body></html>