[Qgis-psc] Fwd: QGIS 4.0 publicly announced - right time for propose and implement breaking changes?

[Régis Haubourg]

On 25/04/2025 00:34, Vedran Stojnović via QGIS-PSC wrote:
> Hi Regis and Richard,
>
> thank you very much for your comments. I think that you slightly 
> misunderstood the point what I am trying to say. Let me try to explain 
> better:

I think I did understand your point, which is try to take benefit of a 
major release to open discussions on massive changes.
I think this is not how QGIS4 has been planned. We are mainly upgrading 
to Qt6 and dealing with the impacts of this on plugins and python 
bindings + a few features that already were in the classical 
developpement workflow, through private funding, benevolent work, or 
Grant Proposal program.

But my point is that it is always time to discuss any matter you feel 
necessary, we have quite a continuous development workflow.
Yes, we have an endless issue and feature requests list. This does not 
mean they are forgotten. Any idea should be filed as a feature request 
for later reference. Any issue should be filed also ( of course, triple 
search before to not create duplicate).

But this doesn't mean things will happen by themselves. We don't have 
billionaire funder behind us, so the questions always end in finding 
ressources to make things happen.

- you have something critical for your organization ? First discuss it, 
check if you are alone or not. If you can, try to get fundings in your 
organization, which means explain again and again that free software is 
not free, and every professional tool used to create value should be 
backed by budgets, so that you can act when facing a blocker situation, 
or engage ressources to improve things in the long run.

- Your organisation is too small or can't afford this ? You can engage 
in a local user group and get funds to make things happen, like the 
Swiss , Deutch, French (and more) user groups are doing.

- You always can fund QGIS.org, directly AND/OR through a local user 
group / AND/OR through you organization. This will fund grant proposal 
and bugfix programs.  You can't target your funds, but you can discuss 
upstream to make Grant proposal happen, and vote for it through your 
user group.

- You can commit yourself to coding yourself of course. It is quite an 
involvement these days given the code base and quality standards we 
have, but not impossible and very encouraged !

>
> We aren't short on time to implement my examples/proposals, but we are 
> short on time to define *the concept of a way to propose breaking 
> changes for the next major release *(assuming we want to have it for 
> 4.0) and only then, possibly, discuss and implement some of these 
> changes that I noted - *but that's another topic*.

There is no real hurry in fact. The annoucement of QGIS4 falsely created 
to feeling, but QGIS is a rolling release. Yes, we will pause a bit to 
help in QT4 transition, and the queue of features will pile up a bit, 
but it won't stop.

>
> The examples that I gave are some things that *I would* *propose* 
> (through a new system)**as a fundamental/breaking change - and they 
> are coming from my experience mostly as a QGIS user, QGIS instructor 
> and GIS implementer, not as a QGIS developer/contributor.
>
> Some changes, feature requests and bug-fixes make sense only on a 
> major release and I think that they do not fit well as QEP.
> But these proposed fundamental/breaking changes should definitely be 
> (in my opinion):
> 1) discussed by bigger audience - to see others point of view on same 
> change, because QGIS covers many fields of use,
> 2) reviewed and commented by core developers,
> 3) approved by someone from PSC,
> [ 4) ] optionally, but not obligatorily, funded by QGIS organization - 
> for important changes that need more work

Agreed. I myself still have ideas from 10 years ago that didn't happen. 
But the critical things I badly needed happened. Either because I got 
involved to have the discussion happen, on the lists, issues, real world 
events, phone calls to developers to get real insights, and via fundings.
I don't have the skills to code, so I focused in helping coordinating 
some events, gather funds, translate things, communicate.

So go ahead, please start separate threads for each idea you have. Some 
will be seeds for the future and won't grow by themselves. Some are 
quick wins that will happen because a magical elf will be reviewing the 
exact part of the code base at the moment he reads this threads.


>
> We have a concept of QEP which functions well, but I see QEP as a 
> proposal for new cutting edge feature implementation that hasn't 
> existed yet, which will bring it's own new possibilities and bugs.
> Other problem with QEP is that it's targeted to developers. 
> Developers/companies propose a new feature and implementation details 
> and then themselves do the work and implement proposed feature. But, 
> what if I'm not a C++ developer?
> What if I do not know at all how to implement a change? But I use QGIS 
> everyday and I do know, from personal experience with QGIS and other 
> GIS related software that something isn't implemented how it should 
> be, or can be changed in a way that better suits end users.*

QEP are like Requests for Comments, a place to propose changes. As 
always, very generic discussions won't trigger real work. So a 
successful QEP must be backed by a dedicated analysis, developpers will 
quickly jump to implementation questions and stress you out there. I 
already had pure UX ideas in mind, but no idea how to implement them. 
You can launch the discussion, and hire someone to help you write a QEP 
that become of real proof of concept. Selective masking was done this 
way, idea first, then POC implementation, failure, another POC 
implementation, then core implementation. Swiss user group, and Andreas 
pushed hard to make things happen.

>
> Of course, we can make a feature request as an issue on GitHub, but if 
> it's a breaking change no one will implement it because it will break 
> automated workflows, existing models, scripts and so on for who knows 
> how many users...

If a feature request breaks thing, it should be written with a QEP.  
Migration already have been done when bringing massive changes. I 
remember labeling engine changes, symbology changes that had migration 
code embedded.

> My opinion is that this approach only pushes this feature request to a 
> "issues graveyard". Two of these examples are #29100 and #54509 - they 
> are definitely implementation mistakes and both of them should be 
> fixed, but who dares to make such a change when current implementation 
> is present for who knows how much time.
> If you ask me, the only right time for these changes is on a major 
> version change and these changes should be properly documented so that 
> users can have easier/non frustrating transition to a new version.

Issue graveyard is the symptom of the gap between the real success of 
QGIS, and the number of users, facing the very small pound of 
contributors ( € & worksforce ).  Triaging thousands of issues is a 
massive work, you can't blame the community to not be able to cope with 
that flood. With more fundings, we will be bale to hire permanent staff 
to triage this, just like we are currently doing with infrastructure, 
website, documentation.

I understand your expectations in terms of quality and experience for a 
version change. This is why we don't trigger the "massive" QGIS 4 
rebuilt. Let's tackle things that can be achieved.

>
> I believe other users and developers have more examples like this and 
> that's my point with this email - to agree on concept for proposing 
> breaking changes and to make them visible and discuss-able.
> Should it be like QEP process, or just a label and milestone mark in 
> GitHub issues...??? We're only 6 months away from major update, but 
> there is no 4.0 Milestone on GitHub, additional to that we have only 
> one label that marks breaking change and that is "API Break!".
We don't use a product owner agile sprint planning. You could propose 
this. That would maybe help in displaying a roadmap where it is easier 
to show in advanced what should make it to a new release.

As we are having a fixed date release, currently you see what makes it 
into a release when the release is tagged. It is really hard to know 
this before hand, because we are a decentralized community. Nobody has 
control on the planning of each contributor's agenda.


>
> Personally, I'm a bigger fan of a QEP process type - I would love to 
> see something like "QBCP" (QGIS Breaking Change Proposal) process, e.g.:
> - two months for collecting proposals - well described, each proposal 
> having it's own page
> - one month for discussion and decisions on what to accept / reject / 
> postpone till next major version
> - two months for development sprint and preparing documentation on 
> accepted breaking changes in new version
> - one month for finishing touches
>
> Differently from QEP, the one that proposes QBCP doesn't need to know 
> anything about programming, just to point out (and well describe and 
> provide valid arguments) a breaking change for new version. Core 
> developers should be able to immediately reject and close proposal if 
> recognized as too complicated or not doable for any reason.
Beware of the pandora box. Proposing changes is easy. Making them 
feasable only happens by discussing with developers ( fund them if you 
can, you will have more time from them), gather funds. We the goal is 
clear and the implementation details clear enough, then it is time to 
discuss real roadmap.
Pushing a major change too soon, without knowing feasibility probably 
won't happen in QGIS. Any accepted change must pass the code review and 
integration test barrier. It takes commitment :)

> My only goal is to make QGIS more friendly by default and better 
> suited for end user. I hope that my idea is now clearer.

It is very welcome! I'm just sharing my experience on how to make things 
happen when being a end user or a GIS administrator, now being a PSC 
elected member.

The free software model is incredible, but we are facing growth 
challenge for sure. I think QGIS.org is doing great here, our budgets 
keep on growing allowing for more professional service every year, while 
still be community driven.  We still have a lot a 100% benevolent areas, 
like triage, code review, marketing, translation, UX discussion.  Let's 
not blame benevolent for their hard work in the past, better to thank 
them, and help in getting paid folks to go a step beyond.

>
> Sorry for long email and thank you for reading.


With pleasure, your energy is really welcome!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20250425/21fbd128/attachment-0001.htm>