<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 8 nov. 2019 à 09:33, ElPaso <<a href="mailto:elpaso@itopen.it">elpaso@itopen.it</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I'm with Jürgen on this, I think we all are responsible developers <br>
acting for the good of QGIS and I didn't see any abuse on direct commits <br>
in the past few years.<br></blockquote><div><br></div><div>While not strictly talking about abuse, there has been quite a few direct push commits which broke the CI.</div><div>That generally meant looking at someone else work to fix things, sometimes by several persons at the same time.</div><div>It also means all last PRs jobs that have to be restarted.</div><div>It gives a bad image/impression.</div><div>It's frustrating.</div><div><br></div><div>One saves himself about one hour time to see his work integrated in the final branch.</div><div>All the good soldiers in the Travis queue are good for a restart.</div><div><br></div><div>In the history of breaking commits, it's always "small and insignificant changes which won't affect the build or the CI". I made a few of these in the past too.</div><div>Just because we don't have docker and clang installed in our brains ;)</div><div><br></div><div>What are the valid arguments to allow direct pushes?</div><div>I can see only one: the release process might requires this since it relies on the branches themselves.</div><div>But this was clearly not the case in the last event.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the contrary, I think I should have committed to master directly to <br>
correct a PR of mines that I merged by mistake the day before 3.10 <br>
release (<a href="https://github.com/qgis/QGIS/pull/32369" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/32369</a>) instead of waiting for <br>
an approval that didn't arrive in time (in this case it wasn't really a <br>
big problem though).</blockquote><div><br></div><div>OK, this might be a valid reason: to fix merge errors.</div><div>But this really sounds like an edge case to me. </div><div>Anyway, this directly fit in the release process window I was mentioning above, which might require a special treatment.</div><div><br></div><div>So this could be a proposition.</div><div>Enforce PRs in standard time but allow direct push by a list of safe core-devs during the release process window.</div><div><br></div><div>Cheers,</div><div>Denis</div></div></div>