[OpenLayers-Dev] Different lon and lat map resolution (and
tschaub at openplans.org
Fri Nov 2 12:57:49 EDT 2007
Jachym Cepicky wrote:
> Tim Schaub píše v Pá 02. 11. 2007 v 09:43 -0600:
>> 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?
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
>> 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 Cepicky wrote:
>>> I submitted new patch set to #889 , 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
>>>  http://trac.openlayers.org/ticket/889
>>> Dev mailing list
>>> Dev at openlayers.org
>> Dev mailing list
>> Dev at openlayers.org
More information about the Dev