[OpenLayers-Dev] OpenLayers 2.8 RC2

[Christopher Schmidt]

On Wed, May 13, 2009 at 05:51:03PM -0400, Christopher Schmidt wrote:
> Sorry, but AFAIAC, I have major concerns about Open Layers at present, not
> all of which can definitely be pinned down on RC2, but they are serious
> enough to impact my applications, and therefore, I feel they need to be
> addressed as part of or before v2.8.  My concern in a nutshell is that, as
> far as my applications are concerned, RC2 may be introducing as many or more
> bugs than it's fixing.

As I have always said, I am perfectly willing to take into account any
*minimal demonstrations* of bugs that are apparent in 2.8 that were not
present in 2.7. These would be regressions, and should be fixed before
the final release. Minimal usually means "150 lines of code total or
less", or an explanation of why more lines of code are needed, so that
others can narrow the problems down.

Your test cases, included below, and previously used many times in
comments, are not minimized. There is no way that I am going to read
through 150kb of code to find a bug. 

Reducing your test case allows:
 * You to potentially identify -- and work around -- the cause of your
   problem
 * developers to help you more easily
 * Others to more easily replicate your problems.
 
Generally, in the process, you can also make a 2.7 v 2.8 comparison
directly. Doing this greatly improves your chances of getting something
marked as a regression. Over time, browsers change, and bugs that are
difficult to reproduce may be the result of *browser8 changes rather
than OpenLayers changes.

Several of the tickets you have opened have had responses, essentially
saying "I can't make this happen in anything other than your
application." What this means is that we have made a good faith effort 
to resolve your problem, and are unable to understand what causes it. In
that case, I see no reason to further delay a release, since 'more time'
will not result in the situation changing.

Minimal test cases are absolutely required in order for me to consider
blocking a release. Several users have successfully provided minimal
test cases that demonstrate their problems, and as such, 2.8 is working
to resolve them.

> In all that follows, I am concerned about the behaviour of the two major
> applications using OL that I have written, both now using RC2, which show
> directional markers on a Google and/or (in the UK) an Ordnancee Survey map.
> 
> The first is my Satellite Alignment Calculator that shows where to point a
> dish to receive a given satellite:
> 	http://tinyurl.com/o62x3d
> ... standing in for ...
> 
> http://www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteCalculato
> r.html?iWhereHow=C&iUKPost=rg6+4aw
> 
> The second is a similar, but of necessity of more complex coding, UK
> Terrestrial TV Aerial Alignment page:
> 	http://tinyurl.com/qq5ylh
> ... standing in for ...
> http://www.macfh.co.uk/Test/UKTerrestrialTVTest.html?iRxWhereHow=C&iRxPost=r
> g6+4aw&iRxHeight=10&iTxWhereHow=C&iTxSel=SU527568
> 
> Both of these pages have notes to explain the various browser limitations on
> their use, which I hope you will read, and the worrying thing is that these
> notes are getting longer, not shorter ...

I see no such notes on either page -- nor do I even see a map on either
page. Again, *minimize your test case* if you want developers to look at
it.

> The former page has been running for about six months now.  When I first
> published it, using v2.7 (/api/), I tested it exhaustively, so I know for
> certain that everything worked flawlessly in FF3, but there were certain
> well defined problems in IE6&7 with the Google baselayers shifting as
> described in http://trac.openlayers.org/ticket/2078, which I fixed by
> disabling all DHTML before creating any maps in IE6&7.

FF has changed several times in the last 6 months. It would not be the
first time that changes in the underlying browser have introduced new
problems. It is also not unlikely that changes in OpenLayers are causing
this -- but without a clear demostration, side by side with 2.7 and 2.8,
it is almost impossible to determine. (And with the limited reproduction
information, it's not worth my time to look into the issue.) 

> But since then, things seem to have got worse.  I'm certain that all the
> following are new problems:
> 
> 1)	The shifting Google baselayers problem is now cropping up all over the
> place.  Something new has definitely been broken.  My latest discovery is
> that, at least under RC2, it is invariably caused by using the Print Preview
> in FF3, but directly printing the pages has no such effect (work that one
> out if you can, it seems totally illogical and bizarre to me).

Set up two pages side by side with the minimal possible number of lines
of code to resolve this problem.

> 2)	If you choose to print only selected pages in FF3, the maps are blank,
> but if you print the entire document, they print properly.

It's not clear to me if you are talking about 'blank' in the browser, or
in the printout. In the latter case, OpenLayers has never sought to make
printing easy or efficient. There are other tools that you should use,
and the differences in browser printing make the idea of doing so
completely impractical. 

> 3)	Still in FF3, in the Satellite Calculator, if you print the Hybrid Base
> Layer, the marker is broken  -  literally, it prints in several sections,
> which seem to coincide with different tiles, and which may not be colinear
> or even all point the same direction!  However, if you reload and select the
> Satellite Baselayer, that prints correctly, just as the Hybrid Base Layer
> used to do.  Again, the logic of that completely escapes me.

It sounds like you are talking about behavior with printing on top of
Google Maps inside OpenLayers. That is *far* beyond the level of
functionality that we have put any effort into making work. In this
case, not only could the OpenLayers library be at fault -- so could the
Google library, which changes on semi-monthly basis. Without a direct
2.7 to 2.8-rc comparison, it is impossible to pin this type of problem
down.  

> 4)	In IE6 (and therefore probably 7), particularly in the more complex
> Aerial Alignment Calculator, with either api or RC2, with the Satellite Base
> Layer at maximum zoom, you may not even get a marker in print preview,
> though if you do it will probably print.  If you do, and if you change
> transmitters (likely local ones are Crystal Palace, Guildford, Hemdean,
> Midhurst - select them using the mouse, being careful for this test not to
> select any others in between, though of course in real life a user may well
> do this), the marker is increasingly unlikely to appear in the print
> preview, and ultimately may not even appear in the map proper.

Okay.

> 5)	There is also the scrolling bug problem, which can very definitely be
> ascribed to RC2.  It doesn't happen under 2.7:
> 	http://trac.openlayers.org/ticket/2054

This is a perfectly reasonable bug report, and is likely that it should
be fixed along the lines of http://trac.openlayers.org/changeset/8936 .
However, unless I see something working in 2.7, and not working in 2.8,
I don't make it a blocker.

> In summary, as far as I am concerned, there seem to be more problems using
> OL maps now under RC2 than there were six months ago under 2.7, though how
> much is due to say, poorly tested FF version updates, and how much to RC2, I
> can't say for sure.  But I desparately need RC2 to deliver much needed
> greater reliability, not less.

If you need something, you are always welcome to create patches and
attach them to tickets. If I have missed you doing so, please feel free
to point me in the direction of patches to fix your problems, and I will
make it a personal priority to review them for possible inclusion in
2.8.

OpenLayers developer time is not an infinite resource. None of us get
paid to work on it, and it is my belief that delaying a 2.8 release for
the issues you have reported is unlikely to be more helpful to users
than not delaying it, based on what I know now. This determination is
based on:

 * Reproducibility of issues
 * Likelihood of other users reporting the same issues
 * Likelihood of issues being *new in 2.8*. 
 
I think that there is likely some small number of changes that are in
2.8 which are more likely regressions in supported behavior --
specifically #2054. However, with no ability to reproduce the problem
reliably, there is no way to know if we have fixed the issue, and until
we can establish how to *cause* the problem, it's very difficult to
think about how to fix it.

In the end, OpenLayers 2.7 is always available as an option to you. I
have no desire to force anyone to stick with a previous release, but if
you have issues you are unable to reliably reproduce, and you find that
an earlier version works well for you, then using that version is
probably the easiest way to solve your problem. (I personally have one
application stuck on OpenLayers 2.1, simply due to lack of time to
upgrade it.)

> Not what you wanted to hear, no doubt, but then it wasn't exactly good news
> for me, either.

I appreciate that you have taken the time to outline these problems.
However, until such a time as you can create clear, concise test cases
that can easily be tested with OpenLayers 2.7 and OpenLayers 2.8 sie by
side, it is unlikely that OpenLayers developers will be able to help you
resolve your problems. Of course, if you can find and fix the problems
yourself, we will gladly take patches, and integrate them as soon as
makes sense.

At this time, #2054 is the only issue that you have reported in
sufficient detail that I believe it should be considered for possible
inclusion in 2.8. For the time being, I have marked the ticket as
targeted for 2.8, Meaning that a developer will need to address the
ticket in some way before the next RC is made available. This delays the
release of 2.8 futher, and is of possibly limited utility to other users
-- since no one else has reported it -- and as such, the resolution may
be to kick it back forward without sufficient confirmation or ability to
reproduce.

It is in your best interest to make your issues small. Small issues are
easier to deal with. Your existing large pages do not, in general,
provide concise test cases to determine the source of problems -- and
even if they did, if the solution isn't apparent, there's always the
chance that it can be considered not importent enough to further delay a
release. There are no promises that somethign will be done on *any*
ticket other than those afforded by our release procedures.

Best Regards,
-- 
Christopher Schmidt
MetaCarta