<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Jürgen,</p>
<p>You are right. The rules are clear and we should not add
exceptions all the time. The dates are clearly communicated to
everyone.</p>
<p>I agree with Tim that it makes sense to discuss how we can
improve the situation with the PR queue - to get more PRs reviewed
that were submitted by non-core committers.</p>
<p>Andreas<br>
</p>
<br>
<div class="moz-cite-prefix">On 27.10.2017 23:25, Jürgen E. Fischer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20171027212552.m6462cjbvnwfmorv@norbit.de">
<pre wrap="">Hi Andreas,
On Fri, 27. Oct 2017 at 17:58:05 +0200, Andreas Neumann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">As to reviewing the PR queue: no idea how much effort would mean, but it
would have to be done quickly (e.g. within the next week). Jürgen has to
comment on that. We can spend some money on getting the PRs reviewed, but I
would need an estimate (e.g. x days).
</pre>
</blockquote>
<pre wrap="">
Not sure how. The rule is clear - feature freeze means no new features. So
all features have to be in (committed to master) prior to the freeze. There is
no rule for exceptions - or one that makes it my buck. I just fix the dates
after we discussed them, make the release (and package it).
Core committers can commit anything they see fit prior to the freeze (they got
that privilege because we trust them). It's not required to run commits it
through PRs first or have PRs reviewed and/or merged by and other core
committer. If they still use a PR and get noone interested to review and
merge, they can still merge it themselves (no news is good news).
If other contributors want PRs merged, they have to find a core committer to
merge it for them (rub them the right way, advertize it and get users to cheer,
hire them, whatever helps). We're not obligated to merge anything - or pay
someone to review them. But if it's a feature PR, it shall not be merged in
freeze. When the PR was filed doesn't matter.
I didn't arbitrarily set the freeze date - actually originally 3.0 should be
released when ready and not on a fixed schedule. The date was requested and
suggested by the key people doing the work - and even already moved once as
their estimation was apparently too optimistic.
The point of the freeze is to give us time to stabilize and fix bugs before the
release. We also discussed how much time is needed for that. Merging PRs
after the freeze would also require to discuss it's impact on the release date.
Jürgen
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</body>
</html>