On Sat, 24 Aug 2019 at 18:40, Giovanni Manghi <giovanni.man...@gmail.com> wrote:
> As someone else said is not true that a "bug is a bug": while certainly there > are issues that is not easy to classify if they impact a lot or not, the vast > majoity is easy to to say if they are important or not. Do not confound the > fact that maybe a ticket do not gets much attention or comments: just a few > people actually do that (file tickets, comment), part of them were also > educated to have faith and expect fixes (of important issues) at least in the > upcoming LTR releases, sometimes just to wait in vain (just because the the > paid bug fixing effort do not comes with any sort of priority list). Putting aside the rest of the conversation regarding regressions for now, something I'd like to see clarified is what exactly classifies as a regression? There's SO much users can potentially do in QGIS which goes far beyond the original design of any particular feature, and which works by sheer chance alone. If this breaks in a future release, is it really a regression? To use a ridiculous example, if I wrote a custom script which relied on hooking into QGIS dialog's widgets via raw PyQT api, and then that dialog is rearranged in future and the button I was tapping into is removed -- is this really a regression? I'd argue strongly not, and that all along I was playing it dangerous by relying on unintentional behaviour. So maybe something explicit like: "a regression is a clearly documented feature (or a feature with pending documentation ticket), or a feature covered by existing units tests, which breaks". This means: - clicking the browse button in the file attachment widgets crashes qgis: regression - a project which depends on postgres foreign data wrappers to evaluate a default field value by performing an aggregate on a related layer from the current project breaking in a future release: not a regression Nyall > > have fun there > > -- G -- > > > > >> >> Yesterday at a dinner with many well known friendly faces, a discussion >> started about the priorization of issues. >> >> One of the main problems when deciding which issues to tackle is, that a >> developer perspective often differs from the one from the average user >> perspective. >> >> So we thought it might be a good idea to start giving our users a bigger >> voice in how bugs are prioritized - and how the projects funds are spent >> - by giving the developers more information about the "impact footprint" >> of issue reports. >> >> *In short: if you particularly hate an issue (or two or three) go to >> this issue on github and just give the first post of it a thumbs up****.* >> >> The following link will then show the leaderboard of annoying things >> >> https://github.com/qgis/QGIS/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3ABug >> >> While there is no guarantee that these bugs really will be solved first >> (there are a couple of other things also to take into account, like a >> well defined solution being at hand) this should give us a much better >> (democratic) idea of the often-cited user expectation. >> >> Thanks for reading >> >> Matthias > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer