[Qgis-developer] September 1 branch for release

Tim Sutton lists at linfiniti.com
Sat Aug 31 12:07:44 PDT 2013


Hi Larry




On Sat, Aug 31, 2013 at 11:28 AM, Larry Shaffer <larrys at dakotacarto.com>wrote:

> Hi Andreas,
>
> On Sat, Aug 31, 2013 at 2:43 AM, Andreas Neumann <a.neumann at carto.net>wrote:
>
>> Larry. I would suggest you take the time you need. The QGIS server is
>> most of the time installed from source and is therefore not too tightly
>> coupled with the official QGIS Desktop release.
>>
>
> The bug (at least the main one, noted in the issue) is not in the
> mapserver code. It is definitely in QgsPalLabeling. I can fix it, but it
> screws up drop shadows and some other labeling components. However, I am at
> a complete loss as to why I am getting different font output resolutions
> between *servers*. Again, the only way to test this is to complete a
> reasonably extensive test suite, used across many platforms/setups.
> Otherwise, even reports from testers will be time-consuming to go over,
> without such a baseline for testing.
>
> I really believe I can do this within the next week. Otherwise, I think it
> would be asking too much of the project to 'hold off' for another week
> beyond that.
>
>  Even if it is not installed from source it is relatively easy to publish
>> QGIS server packages independent from Desktop.
>>
>
> Not so on Mac, where it is included in the main app bundle. However, since
> William is the main distributor for the stable version, I suppose it could
> have a secondary release. My feeling is the bug should be reasonably
> squashed right now.
>
>
>> Btw: I dont see any of these font problems at my QGIS server
>> installation. I would have noticed it since I use QGIS server quite
>> extensively.
>>
>
> I would love to know how that is possible. I've not seen a setup that
> doesn't exhibit the issue yet. Maybe it slight enough that you just don't
> 'see' it on manual visual inspection. Can you possibly run the current
> limited labeling server test from the build dir on that machine (or one
> with access to that web server)?
>
> It is run individually with: ctest -R PyQgsPalLabelingServer -V
>
> It should fail due to lack of configuration, but give info on setting up
> the local test server configuration file, e.g. [0]. Unfortunately, the
> misconfiguration, which causes the test class to be skipped, does not
> register as a FAIL at dash.orfeo-toolbox.org. Example of failed test,
> after local server configuration, for my Mac nightly build setup [1].
>
> It should also definitely fail because the current control image is from
> Mac (font handling differences). Read the Python test file [2] to see other
> env vars you can set to create a new set of local control images for your
> platform (just don't commit them upstream to QGIS source, yet). You will
> need a set of control images for canvas too, since one of the test classes
> is to crosscheck server output against canvas's (the actual issue at hand),
> as well the comparison of expected server output.
>
> [0]
> http://dash.orfeo-toolbox.org/testDetails.php?test=18860662&build=127142
> [1]
> http://dash.orfeo-toolbox.org/testDetails.php?test=18875858&build=127203
> [2]
> https://github.com/qgis/Quantum-GIS/blob/master/tests/src/python/test_qgspallabeling_server.py
>
>
Personally I would prefer that we branch for release tomorrow night and not
wait another week. The reason for this is that it would be good to allow
enough time for a wide range of packages to be built from the release by
the time FOSS4G comes, and that it would be nice to have the release well
behind us by the time the upcoming hackfest starts. Also I am taking into
account Andreas' comments above. Let me know tomorrow how things are
looking and we can consider whether to extend the branching date by a few
days to accommodate you.

Regards

Tim




>  Regards,
>
> Larry
>
>
>> Andreas
>>
>>
>>
>> Larry Shaffer <larrys at dakotacarto.com> schrieb:
>>>
>>> Hi Michael,
>>>
>>> On Fri, Aug 30, 2013 at 8:28 AM, kimaidou <kimaidou at gmail.com> wrote:
>>>
>>>> Hi all
>>>>
>>>> I have another person who told me "I have weird label sizes with QGIS
>>>> Server".
>>>> Larry, sorry to ask again, but do you think you will be able to solve
>>>> http://hub.qgis.org/issues/8068 before the 1st ?
>>>>
>>>>
>>> Ugh! I was hoping to have that done by now, but several things conspired
>>> against me this week. This is a very significant issue and very laborious
>>> to test across platforms. Also, it appears to even be different between
>>> host web servers (no idea how that's happening)!
>>>
>>> I very much apologize for the delay in a fix. Here is why it is a
>>> time-consuming fix:
>>>
>>> * The difference in resolutions of output paint devices affects
>>> EVERYTHING in the new labeling features (e.g. shadows, backgrounds). This
>>> is because of the means in which I coded the 'storing' of the label
>>> component's painting to canvas, so that I can use that info to later create
>>> the drop shadows, etc. When I fix one part of the code, I have to
>>> *visually* test many variations that might be affected (e.g. server, PDF
>>> and SVG exports). This is because there were no unit tests for the labeling
>>> code at all (I take responsibility for some of that).
>>>
>>> * So... I made the uncomfortable decision to create a comprehensive
>>> labeling test suite right now. The idea being, I add a single unit test and
>>> it is inherited by classes that test its output to canvas, composer (PDF,
>>> SVG), and server (and composer and server outputs against canvas), and have
>>> any errors pop up test comparisons in a web browser. This way I can
>>> immediately open a virtual machine for other platforms, build the tests and
>>> *see* all of the errors in browser tabs. (about 100 times faster)
>>>
>>> * I am not done with the test classes (need to finish composer's, at a
>>> minimum). Hope to have it done today.
>>>
>>> * I also found it very time-consuming to configure/maintain test web
>>> servers on all of the test machines. So... I made not only an Python
>>> interface to help test server output, but also recently coded an embedded
>>> fcgi spawner and Python interface to it (fcgi-spawn and flup client). This
>>> means a completely separate fcgi process can be spawned and queried for
>>> unit tests (as a background process), regardless of the the machine's
>>> installed web servers/configurations.
>>>
>>> The embedded fcgi spawner also means that for 2.1 we can have a menu
>>> item 'Show project in test server...' which can pop up a QWebView connected
>>> to the embedded server :^), assuming the data sources can be concurrently
>>> accessed.
>>>
>>> So... why did I take the long way around to try and fix this? Because
>>> the variations are so large that without tests I had no reasonable way of
>>> determining if my 'fix' didn't break something else.
>>>
>>>
>>> **Essentially, at this point, I might be able to fix it by Sunday, but
>>> having 1 more week, I know I can.**
>>>
>>>
>>> Thanks for any update, we can help by trying your branch if needed
>>>>
>>>
>>> Yes, that would be greatly appreciated! I would need to know which OS's
>>> you can test under (the more the better) and which host servers (Apache,
>>> Nginx, etc.).
>>>
>>> If I can get my work cleaned up today, I will let you know. I need to
>>> finish the minimum test suite so that you can also run the tests to help
>>> verify the fix is good to go. I will not bother to finish coding the local
>>> embedded server's install and unattended spawning, since you can manually
>>> spawn/kill it for the duration of the tests.
>>>
>>> Regards,
>>>
>>> Larry
>>>
>>>
>>>
>>>
>>>> Cheers
>>>> Michael
>>>>
>>>>
>>>> 2013/8/28 Paolo Cavallini <cavallini at faunalia.it>
>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Il 28/08/2013 01:51, Larry Shaffer ha scritto:
>>>>>
>>>>> >         Assuming you intend to go ahead with 1 Sept tagging, will we
>>>>> still be able to
>>>>> >         commit to the master branch in between 25 Aug and 1 Sept?
>>>>>
>>>>> Hi Larry,
>>>>> will this include a fix to the blocker?
>>>>> All the best, and thanks.
>>>>>
>>>>> - --
>>>>> Paolo Cavallini - Faunalia
>>>>> www.faunalia.eu
>>>>> Full contact details at www.faunalia.eu/pc
>>>>> Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.14 (GNU/Linux)
>>>>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>>>>
>>>>> iEYEARECAAYFAlIdmH8ACgkQ/NedwLUzIr6dkACePVcB2o4O71T8uXRRbPe/XgKl
>>>>> /5sAmgNh28zn8Bwy0OeSf0UXGt3ynqu2
>>>>> =+ZZU
>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> Qgis-developer mailing list
>>>>> Qgis-developer at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Qgis-developer mailing list
>>>> Qgis-developer at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>>
>>> ------------------------------
>>>
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>>
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Irc: timlinux on #qgis at freenode.net
==============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130831/c39660f2/attachment.html>


More information about the Qgis-developer mailing list