+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: * https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition * Hire me: http://goo.gl/BYRQKg ************************************************************************************************** On 8 May 2018 at 08:26, Alessandro Pasotti <[email protected]> wrote: > On Tue, May 8, 2018 at 1:15 AM, Nyall Dawson <[email protected]> > 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
