[QGIS-Developer] 32 by 3.2?

Luigi Pirelli luipir at gmail.com
Tue May 8 01:43:59 PDT 2018

+1 for all points... sorry to be not so helpful in this period doing my
review part for lack of time

I would close some my PRs that I've no time to work on, but I know there
are companies interested about that fixes. Would be fair they take care of
that. Just matter to setup a appopriate postgis/pki/docker setup to
reactivate some PKI tests.

Luigi Pirelli

* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* Hire me: http://goo.gl/BYRQKg

On 8 May 2018 at 08:26, Alessandro Pasotti <apasotti at gmail.com> wrote:

> On Tue, May 8, 2018 at 1:15 AM, 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 :)
>> Thoughts?
> These are all good ideas!
> I'd expecially go for 1, 3 and 4.
> --
> Alessandro Pasotti
> w3:   www.itopen.it
> _______________________________________________
> 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/20180508/9187db4d/attachment.html>

More information about the QGIS-Developer mailing list