<div dir="auto">hi All, <div dir="auto">thanks for all the inputs. It seems to me that the general consensus is that we should have a testing phase at the beginning of a new release cycle.</div><div dir="auto"><br></div><div dir="auto">I think that communication is key and that our user need to be clearly instructed on what this releases are all about. I see more of a communicative issue here than a technical one. </div><div dir="auto">We are probably not doing a great job in letting people know that the they should be trying our weekly packages before the official release and formalizing this with something like a "release candidate" naming would make this kind of communication easier and clearer.</div><div dir="auto"><br></div><div dir="auto">3.18.0 to us is a new package from a new series but, for regular users or even for some power users, it is just a number whereas "release candidate" is something that automatically signals what the package is about. </div><div dir="auto"><br></div><div dir="auto">I would suggest renaming .0 packages into release candidates and allow 2 weeks testing. After that we can release the next package and start the regular monthly bugfixing packaging intervals.</div><div dir="auto"><br></div><div dir="auto">Additionally we could allow (If during the two weeks of testings we recognize bad issues like it happened with the last release) creating new release candidate packages and postponing the release announcement.</div><div dir="auto"><br></div><div dir="auto">I really think this kind of approach would benefit the project a lot since we would not be shipping code that has not been tested at large and we would have a simple way to tell people that we're getting a new version ready and it is now time to test it heavily.</div><div dir="auto"><br></div><div dir="auto">We've had a fantastic feedback loop and according rating increase of 0.4 stars in QField since we started releasing using a similar approach.</div><div dir="auto"><br></div><div dir="auto">I'm convinced that having this together with all automated and semi-automated testing that we do now have will allow QGIS to become even more stable.</div><div dir="auto"><br></div><div dir="auto">Later today I'll rise this at the PSC meeting.</div><div dir="auto"><br></div><div dir="auto">For what is worth, this might also be worth restarting separately the discussion about having only 2 releases per year. In which case I'd suggest allowing 1 month of RC testing.</div><div dir="auto"><br></div><div dir="auto">Cheers Marco </div><div dir="auto"><br></div><div dir="auto"><br></div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, 1 Mar 2021, 18:58 Alexandre Neto, <<a href="mailto:senhor.neto@gmail.com">senhor.neto@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div>Hi,</div><div><br></div><div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 28, 2021 at 11:09 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank" rel="noreferrer">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Isn't the Kiwi user test framework supposed to be directed at<br>
recognising these regressions? Could we get a status update on that<br>
and what needs to be done on pushing that effort forward? (The<br>
<a href="https://github.com/qcooperative/qgis-core-tests" rel="noreferrer noreferrer" target="_blank">https://github.com/qcooperative/qgis-core-tests</a> repo seems to be all<br>
but abandoned...?)<br>
<br></blockquote><div><b><TL;DR></b><br></div><div>1. Yes, indeed, the goal of the QA testing framework [0] is to catch this kind of anomalies before normal users do.<br></div><div></div><div>2. The mentioned repository represents only a sub-part of the QA infrastructure, the work has continued on the kiwi platform (check a more detailed status below).</div><div>3. Putting it simply, to move forward, we now need, community feedback\buy-in, more tests, more testers, and ofc time.<br></div><div>4. Giovanni's freeze/Release candidate proposal is absolutely necessary if we want to be able to catch issues related to packaging, which includes dependencies bumps or changes. It's hard, if not impossible, to test a moving target. Besides, manual testing is a time-consuming activity, one week would be better than nothing but, very short to run all the (expected) test cases, have time to fix the issues, and re-test the fixes.</div><div><b></TL;DR></b></div><div><br></div><div><b>QEP 180 Status</b><br></div><div>Regarding the status of the work, we have:</div><div>- established/proposed a base methodology for how to run tests <a href="https://github.com/qcooperative/qgis-testing/blob/main/README.md" target="_blank" rel="noreferrer">[0]</a>;</div><div>- implemented a TCMS (Test Case Management System) infrastructure <a href="https://qgis.tenant.kiwitcms.org/" target="_blank" rel="noreferrer">[1]</a> using <a href="https://kiwitcms.org/" target="_blank" rel="noreferrer">https://kiwitcms.org/</a> free instance (available for open source projects);</div><div>- created a limited set of test cases (manual tests) on kiwi <a href="https://qgis.tenant.kiwitcms.org/cases/search/" target="_blank" rel="noreferrer">[2]</a>, to serve as examples and for internal testing (so far);<br></div><div>- revived Boundless's the tester plugin <a href="https://github.com/qcooperative/qgis-tester-plugin" target="_blank" rel="noreferrer">[3]</a>;</div><div>- created a limited set of semi-automated test for the tester plugin <a href="https://github.com/qcooperative/qgis-core-tests" target="_blank" rel="noreferrer">[4]</a> (the repo mentioned above), to serve as examples and for internal testing (so far);</div><div>- organized and executed test plans for the 3.16.4 and 3.18.0 releases, for Ubuntu 20.04 and Windows 10 <a href="https://qgis.tenant.kiwitcms.org/plan/search/" target="_blank" rel="noreferrer">[5]</a>, using several nightlies, in an iterative procedure, to polish the process as much as possible.<br></div><div></div><div><br></div><div><b>Next steps (outside QEP 180 - grant 2020 scope)</b><br></div><div>Until the next release (3.20), my plan is to:</div><div>- Create more test cases. This can't be done without the community buy-in, including the developers, that, better than anyone else, know what has been changed during the release cycle, and what functionalities were not possible to fully cover using unit tests. Alessandro already requested test cases for geopackages and spatialite usage in the browser panel, which is WIP.</div><div>- Attract users to become testers and train them.<br></div><div>- Organize the test plans for 3.20 release, in as many platforms as possible (depending on the number of available testers, ofc)<br></div><div>- Execute the test plans and report the issues. This should be done during the feature freeze period, ideally on a full freeze including from packaging or Release candidate.</div><div><br></div><div>More stuff to do:<br></div><div>- Move testing documentation [0] to official QGIS documentation.</div><div>- Create a testing data set for use in tests (or improve QGIS data sample).<br></div><div><b><br></b></div><div><b>Blockers\annoyances</b></div><div>The fact that we are running kiwi on a free instance of <a href="https://kiwitcms.org/" target="_blank" rel="noreferrer">https://kiwitcms.org/</a> has a few limitations:</div><div>1. A very annoying two-step registry process. People need to register on <a href="http://kiwi.org" target="_blank" rel="noreferrer">kiwi.org</a>, and then request access to the QGIS tenant to someone already accepted.<br></div><div>2. No users and group permissions settings. Meaning that all users that have access to QGIS kiwi instance have read and write access to all test cases, test plans, executions, etc... Anyone can make a mistake and erase a lot of work from others.</div><div>3. No public (unregistered read-only) access to test cases and test plans, to use in GitHub and mailing list links. This is not related to the free instance, it's how kiwi works. <br><br></div><div>I think annoyances 1 and 2 could be solved by hosting our own kiwi instance or paying for one of their subscriptions plan (32€/mo).</div><div><br></div><div>For annoyance 3, a self-hosted instance would allow for a workaround. I have opened a Feature Request <a href="https://github.com/kiwitcms/Kiwi/issues/2229" target="_blank" rel="noreferrer">[6]</a> on kiwi github, but obviously, that does not mean it will ever be implemented. I already asked for a cost estimate.</div><div><b></b></div><div><br></div><div>Best regards,</div><div><br></div><div>Alexandre Neto<br></div><div> </div><div>[0] - <a href="https://github.com/qcooperative/qgis-testing/blob/main/README.md" target="_blank" rel="noreferrer">https://github.com/qcooperative/qgis-testing/blob/main/README.md</a></div><div>[1] - <a href="https://qgis.tenant.kiwitcms.org" target="_blank" rel="noreferrer">https://qgis.tenant.kiwitcms.org</a></div><div>[2] - <a href="https://qgis.tenant.kiwitcms.org/cases/search/" target="_blank" rel="noreferrer">https://qgis.tenant.kiwitcms.org/cases/search/</a></div><div>[3] - <a href="https://github.com/qcooperative/qgis-tester-plugin" target="_blank" rel="noreferrer">https://github.com/qcooperative/qgis-tester-plugin</a></div><div>[4] - <a href="https://github.com/qcooperative/qgis-core-tests" target="_blank" rel="noreferrer">https://github.com/qcooperative/qgis-core-tests</a></div><div>[5] - <a href="https://qgis.tenant.kiwitcms.org/plan/search/" target="_blank" rel="noreferrer">https://qgis.tenant.kiwitcms.org/plan/search/</a></div><div>[6] - <a href="https://github.com/kiwitcms/Kiwi/issues/2229" target="_blank" rel="noreferrer">https://github.com/kiwitcms/Kiwi/issues/2229</a></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nyall<br>
<br>
<br>
<br>
<br>
<br>
> I like this idea.<br>
><br>
> Would you see that happen during feature freeze or post release?<br>
> How would this work branding wise, i.e. what will be the name of this, something like beta or release candidate?<br>
><br>
> Matthias<br>
> _______________________________________________<br>
> Qgis-psc mailing list<br>
> <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank" rel="noreferrer">Qgis-psc@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank" rel="noreferrer">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank" rel="noreferrer">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
</blockquote></div></div>