[Qgis-psc] [QGIS-Developer] Feature freeze: Paid developer activities for QGIS 3.0

[Nyall Dawson]

On 2 November 2017 at 22:08, Andreas Neumann <a.neumann at carto.net> wrote:
> Dear PSC and core devs,
>
> There is this ongoing discussion whether we could grant an exception to the
> feature freeze for Nyalls code around layouts (composer replacement) in QGIS
> 3.

On this discussion: Can we also include the possibility of merging
(after review) of the open PRs which restore the GRASS and SAGA
processing providers? In my view these should be strong candidates for
freeze exemptions, given:

1. PRs were in place long before freeze, it was just lack of developer
time for reviews/final fixups which prevented their merge
2. These are critical functionality for QGIS, and their omission will
make 3.0 a "no-go" for many users.
3. I consider these low-risk merges. It's all python code, on which
nothing else depends. In the worst case scenario, if SAGA or GRASS
algs are buggy and unstable in 3.0, is that any worse than shipping
without them? I don't think so. (And to be brutally honest... in the
SAGA case at least, we've never had this functionality as stable in
any release).

> @PSC: can we please have a quick decision on this issue?
>
> @core-devs: since this is also a technical decision with technical impacts
> could you core devs please speak up with your opinion if you would like to
> make an exception for Nyalls layout code, so that it can land in QGIS 3.0
>
> @Nyall: can you estimate when your API-relevant changes would be stable
> enough to be merged into master?

I estimate 2 more weeks and I'd be happy to merge that PR (I have put
it aside for now to work on bug fixing).

This is a tricky one honestly. Unlike the grass/saga exemption I've
advocated for above, swapping out composer for layouts is a high-risk
change. It's 10s (100s?) of thousands of lines of new or heavily
refactored code. And while it's heavily unit tested, there's a big
chance of regressions.

But the alternatives are:

1. Ship with composer, and keep exposing composer API. We'll be stuck
with composer for the life of 2.x, and when layouts lands in 3.2 we'll
end up with duplicate buttons for "new composer"/"new layout", or some
option to switch the print backend from composer/layouts. Ouch! Not to
mention that we'll be forced to carry around and maintain thousands of
lines of old code for the next x years.

2. Ship with composer in 3.0, but remove from bindings (e.g.
https://github.com/qgis/QGIS/pull/5486). Then after thaw I can merge
layouts and drop all the composer code. Downside is no ability to
script or have composer based plugins in 3.0. Upside is layouts lands
with the new clean api in 3.2, and we can have a clean-start then.
Another upside is the additional full cycle of testing for layouts
which means that when it's available to users in 3.2 it should be
rock-solid.

That's me laying out all the options as I see them. I'm honestly happy
to abide by whatever decision the release manager/PSC makes here. I
don't envy their position in making this call (sorry!)

Nyall