<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Feb 22, 2016 at 11:30 AM Thomas Gazagnaire <<a href="mailto:thomas@gazagnaire.org">thomas@gazagnaire.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>That was not my understanding of the proposal: any PR modifying anything can still be merged as long as there is a quora amonst the repo maintainer. I think that was part of the design constraints that Louis and Hannes tried to resolve.</div></div></blockquote><div><br></div><div>Even the notion of repo maintainer is weird: we should target a completely distributed repo, where each package is taken care of by a small set of maintainers (as it is done in Debian, which is not perfect, but working). </div><div><br></div><div>Imagine if Github decided that, as they are at least as smart as the devs who use their platform, that they should have the right to patch whatever code is hosted on Github. Would you keep using such a platform ? I think it's the same here: I don't want anybody to mess with my packages, but I do want to be warned if there is a problem that I should fix.</div><div> </div><div>I think the opam repo maintainers have one opportunity to fix packages (when a new version is submitted the first time), but then, they should not be permitted to modify them anymore, without the permission of the submitter.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>It is indeed important that upstream are aware of issue and we currently do a poor job with that. Would be nice to automatise that by sending emails to maintainers. Anil, can we use @<a href="http://ocaml.org" target="_blank">ocaml.org</a>'s SMTP for that?</div></div></blockquote><div><br></div><div>What are you proposing ? Indeed, we should have a daemon watching the repository and sending automated emails for some kind of simple problems.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr"><div>* a maintainer's fix might be of less quality than an owner's fix, because he might not know why something is done or not done. Discussing with the upstream developer usually is thus a better approach.</div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div>After having spend years (literally) fixing issues in opam-repository, I disagree with that statement. Repo maintainers are experienced OCaml coder, which see compilation error pattern every day. Repo maintainers are also quite active (usually more than package maintainers) and fix issues when they see them.</div></div></blockquote><div><br></div><div>Well, if your goal is to spend more and more time fixing problems in the repo, that's probably the best approach. But if you want to move the work from the repo maintainers to the package maintainers, then you need to spend a little more time communicating with them about such issues. I think the strict approach is better to spread knowledge, and thus on the long term. And automatisation can help a lot !</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I think the current model has some flows but it's still very valid given the current constraints. As I said in an other thread, this is a local optimum. Of course, I'm fine to move to another local optimum if it's better :-)</div></div></blockquote><div><br></div><div>Yes, let's find a better local optimum :-)</div><div>--Fabrice</div><div> </div></div></div>