[OpenLayers-Dev] Different lon and lat map resolution (and other issues)

Fri Nov 2 12:57:49 EDT 2007

Hey-

Jachym Cepicky wrote:
> Hi,
> 
> Tim Schaub píše v Pá 02. 11. 2007 v 09:43 -0600:
>> Hey-
>>
>> Just a quick note to say I understand your frustration.  However, we all 
>> have lots of work to do - and it doesn't make sense to allow 
>> modifications willy-nilly.
> 
> I can understand this. How many people do have write access to trunk?
> 

http://trac.openlayers.org/wiki/CLA

The above page describes who has access to what.  As with all else in a 
wiki, this list requires a person to update it - so I can't say how 
current it is, but I think Erik probably is keeping it up.

>> The above link shows the current patches awaiting review.  Now, I can't 
>> speak for others, but I generally don't take on patch review unless:
>>
>> 1) a ticket really makes sense to me
>> 2) the ticket has a single (obvious unified diff) patch for review
>> 3) the patch includes some tests
> 
> what do you understand with "test" ? Is it working demo? 

There are two types of tests that we like to see:  acceptance tests and 
unit tests (wikipedia is a good reference for terms like these).  In 
general, automated tests are nicer than manually run tests.

See http://trac.openlayers.org/wiki/CreatingPatches for a link to the 
page on writing unit tests.  Our automated tests are really a combo of 
acceptance and unit tests.  We also have some acceptance tests scattered 
around the examples directory.

In short, you should write tests for any modifications.  In OpenLayers, 
these tests should be written using the Test.AnotherWay setup.  If your 
modification represents a change that can reasonably be shown with an 
example, then your patch should also include an example.

So, a ticket that proposes a modification should ideally contain *one* 
patch.  That patch
  1) can be applied cleanly to the trunk,
  2) has inline documentation comments in the NaturalDocs style,
  3) includes tests that run in our Test.Anotherway setup, and
  4) includes an example if appropriate.

You can find more on the wiki that details things here that you might 
not understand.

> 
>> It's probably best if your idea gets some air time.  If there are others 
>> that are interested in it, then the issue likely deserves some 
>> attention.  If nobody else wants the modification, then it's probably 
>> not suited for the library.
> 
> Well, IMHO, usually, if people do agree with something, they likely say
> nothing. People are only raising their hands, if they want to complain.
> I had one positive feedback from one user (off-list), that it is usable.
> It solves my problem - it *could* solve also other people problems. 
> 
> IMHO, the patch with new feature should be accepted always, unless there
> is some serious reason for not accepting it. Patches in general are
> supposed to add new features - make the software more customizable for
> everyones needs. If now I'm the only one, who needs it, who can say,
> there will be nobody in the future?

How does your patch affect vector layers?  Will it work with the 
upcoming Proj4js work?  Is your proposed feature compatible with 
markers, popups, world wrapping, commercial layers, and all other 
current features?  A quick glance at your ticket and attached patches 
doesn't answer any of this for me.  A more robust (and up to date) 
example and tests would help.  And a good understanding of how all these 
other features work is essential to contributing a modification that 
changes map behavior.

> 
> And - I'm posting this to dev list only. Should I post to users list as
> well, to get some kind of support?
> 
>> If there is interest from others (replies to the list, comments on the 
>> patch), then it would probably make sense to add some tests and make a 
>> single patch for your modification.  And yes, if it doesn't apply to the 
>> trunk, it is even less likely to get reviewed.
> 
> If I understand your last sentence right - we are expected to keep our
> patches fresh for several weeks or months? If so, I would have to ask,
> if there could be some better development model(?).
> 
> It is not going only about this one issue - I have several other
> improvements, Marker/Label.js, Popup.js, LayerSwitcher.js and others.
> But I'm asking myself, if it is worth the work, to prepare patches, if
> nobody even reviews them :-(
> 
> Thanks for your answers
> 
> Jachym
> 
>> Tim
>>
>>
>> Jachym Cepicky wrote:
>>> Hi,
>>> I submitted new patch set to #889 [1], which implements different pixel
>>> resolutions in x and y direction. The patches should work with *current*
>>> version of OpenLayers.
>>>
>>> I would also like to ask several questions:
>>>  - when approximately the patch will be added to trunk, or 
>>>  - when approximately will be decided, this will/will not happen
>>>  - what else can I / do I have to do for, the patch will be accepted or
>>> definitely declined
>>>  - do I have to prepare fresh patches let say every week, so they are
>>> still usable for current OpenLayers, or is it enough, post them once,
>>> the project managers will update them by themselves? 
>>>
>>> Now, I did 3rd version of the patch, till now, there was even no
>>> discussion, if the patch should/should not/should under some conditions
>>> be accepted/declined. 
>>>
>>> Sorry, if this sounds rude - this e-mail is not to be understood as
>>> blame. It is just little bit frustrating: If the people are asking for
>>> new features, most general answer is "patches are welcomed". If the
>>> patches are there, nobody wants them. Or, so it looks at least from
>>> here. That is, why I'm asking about the mechanisms of patch
>>> acceptation. 
>>>
>>> Thanks
>>>
>>> Jachym
>>>
>>> [1] http://trac.openlayers.org/ticket/889
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>>
>>> !DSPAM:4033,472b3b42219125210051143!
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
>> ------------------------------------------------------------------------
>>
>> !DSPAM:4033,472b4c68280415332866982!