[QGIS-Developer] 32 by 3.2?

James Shaeffer james at shaeffer.co
Mon May 7 21:39:49 PDT 2018

I personally like this strategy, but as someone who is new to the project and has made only one PR (which was merged rather quickly), how can I help?

This seems to really only concern those who maintain the code, leaving many unable to do much.

On May 7, 2018 4:15:59 PM MST, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>Hi all,
>It's no surprise to anyone familiar with the QGIS project that we've
>got an issue with the Pull Request queue. It's been slowly growing
>over time, recently hitting over 150 open requests! It's a bit of an
>embarrassment to the project (some of these PRs have been open for
>years!), and is likely causing us to lose new contributors and code.
>The usual magic QGIS coding pixies did some work lately and squashed
>the queue back below 100 requests. But the remaining ones are all the
>difficult, unfinished or orphaned PRs...
>PR reviewing is hard. Not everyone can review every open PR due to
>different familiarity with areas of the codebase. (Which is why I
>don't think a funding grant to cover this will ever work
>successfully). And no-one wants to be the 'bad guy" who closes an
>unmerged PR representing someone else's hard work.
>So I propose a "32 by 3.2" sprint, where we ALL collaboratively aim to
>reduce the PR queue to <32 open requests before 3.2 release.
>I think we could achieve this by:
>1. Adopting a hard-line approach to the older, orphaned PRs. Even if
>they have some value or reflect real issues, if no-one is interested
>in cleaning up the request to get it merge ready then we close it.
>2. Adopt a "open-one, close-one" guideline for core committers. Heck,
>I think every core committer has at least 1 or 2 open PRs representing
>various experiments and WIP in unfinished states. These should either
>be finished off, or closed and re-opened when the work is actually
>ready to go. And for test PRs which are "for comment only" I'd suggest
>a QEP is more likely to get better feedback and is the more
>appropriate place for this discussion of this nature.
>3. Closing orphaned or risky PRs which are targeted to 2.18 and which
>have been fixed in master branch.
>4. Sharing the hard work so that the magic pixies don't lose their
>magic powers :)
>QGIS-Developer mailing list
>QGIS-Developer at lists.osgeo.org
>List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180507/e5cb6235/attachment.html>

More information about the QGIS-Developer mailing list