Hi all,
> I think that a carefully used BLOCKER tag makes a lot of sense. > > There are some bugs that we should definitely not be part of a release or > this will seriously impact user's trust in QGIS both as a software and as a > community. > > I also suggest that the ones who take care of the bug queue (kind of QA > managers) should be in charge of managing and lifting the blocker tag. I'm also very much in favor of bringing it back. Just a note: when we added the "blocker" tag (circa 2011) it wasn't because of the "hey please fix this because it impacts me a lot!" kind of tickets. It was added at a point we decided to enforce fixing all the regressions before releasing a new version. During that time the program improved *a lot*, in fact its development and adoption started snowballing, new tickets started rain in and everything become more complicated (and since a while it is even more complicated with both LTR that needs to keep going and QGIS3 to be developed). I agree that we must decide what should be tagged a blocker without any doubt (other than obvious issues as the ones pointed by Nyall). Examples of what, in my opinion, should be a always a real blocker: * a regression that causes data corruption (like the one that caused to compute wrong area in several 2.* releases) * a regression that causes qgis to crash (and it wasn't the case in previous releases) else? cheers! -- G -- _______________________________________________ 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
