Re: [zeta-dev] Proposal: Location component
On Thu, 25 Nov 2010, Tobias Schlitt wrote: > On 11/24/2010 01:03 PM, Henri Bergius wrote: > > Spot > > > > A spot is an actual location on a map. This consists of WGS-84 > > latitude and longitude. Optionally spots may have an altitude, > > timestamp, accuracy and a human-readable description. > > > > Spot should also be able to calculate distance and direction to other > > spots, and to provide a bounding box around them at a given radius. > > > > For display purposes spots also need to provide a way to convert them > > to pretty-printed human-readable coordinates. > > I'm not sure if it is a good thing to couple additional data to a spot > from scratch. Wouldn't it be better to keep this part open to the user, > so that he can extend it to fit his needs? Additional data in OSM land are called "tags". Which can be on: nodes (points), ways/areas as well as on relations. I think it'd be a good idea to try to follow their data model, so that the points we have can be easily used with (or extracted from) OSM data. > I'm not sure, if the service based stuff fits into a base component, > depending on its focus. I would imagine that the pure Location component > should only deal with mathematical representations of geo-data and maybe > leave the geo coding parts to a tiein. If you want to the maths, things get a lot more complicated. THen you need to deal with different projections and coordinate systems and conversions as well. I would like to see something like that, but I'd rather have that in an extension as it can be quite slow. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Location component
On Wed, 24 Nov 2010, Henri Bergius wrote: > Spot > > A spot is an actual location on a map. This consists of WGS-84 > latitude and longitude. Optionally spots may have an altitude, > timestamp, accuracy and a human-readable description. You surely would like to call this a "point" instead? Also, are you thinking of only doing WGS-84 here? > Spot should also be able to calculate distance and direction to other > spots, and to provide a bounding box around them at a given radius. "Bounding box at a radius" ... that doesn't make sense. A box is not a circle :P > Geocoding > - > Geocoding is a service for converting human-readable locations to > actual coordinates (spots). There should be an interface for geocoding > utilizing various online geocoding services like GeoNames and > OpenStreetMap Nominatim. Users of the component should be able to > create their own geocoding service implementations. > > Reverse geocoding > - > Reverse geocoding is a service for converting actual coordinates > (spots) into human-readable locations. There should be an interface > for reverse geocoding utilizing various online geocoding services like > GeoNames and OpenStreetMap Nominatim. Users of the component should be > able to create their own reverse geocoding service implementations. All of those services provide information in a slightly different way though. Especially with admin-levels. There ought to be an abstraction for this. > IP geocoding > > IP geocoding is a service for converting an IP address to an > approximate geographical location of the network. This can be used to > locate users of a website for instance, in cases where browser > geolocationing is not possible. The IP geocoding interface should be > able to talk to at least HostIP web service to perform geocoding. > > 1: > http://mail-archives.apache.org/mod_mbox/incubator-zeta-dev/201011.mbox/%3caanlkti=2j_vhbrmc3x55ekkjojwtuq-=9ddms0zvn...@mail.gmail.com%3e > 2: https://github.com/bergie/midgardmvc_helper_location I am missing a few other location things that would also make sense: - Obtaining the location through Google's geolocation services: http://talks.php.net/show/maps-afup10/18 and http://talks.php.net/show/maps-ipc10/22 (by providing ssid/mac addresses). - Skyhook also provides an interface. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Tue, 16 Nov 2010, Tobias Schlitt wrote: > as far as I can see there are two major points in this discussion: > > 1. Providing updates for single components in short time frames could > bring people to an update hell, when they need to download and upgrade > some components every week. They don't have to. Only for security releases, or when they want to use new features. I think it's a great thing that we can release individual components on such a fast turn around. It means that new features are out (close to) instantly. > 2. The clear target of Zeta to provide components as loosely coupled as > possible would be lead ad absurdum by only providing full package upgrades. > However, I see the argument for not having automatic releases of the > full package whenever a component is upgraded. This would lead the > argument for the full package ad absurdum. Yes. The full package should be twice a year. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Thu, 18 Nov 2010, Tobias Schlitt wrote: > Don't get me wrong, I insist of keeping our PEAR channel as the primary > distribution way. Absolutely. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Thu, 11 Nov 2010, Tobias Schlitt wrote: > On 11/07/2010 11:55 AM, Thomas Ernest wrote: > > > Here comes questions : > > A/ What is your opinion about the proposal automate full package release ? > > B/ What are advantages of separating full package release process from > > component release process ? (It should probably be my first question > > before writing all this stuff :-)) > > For A: I would love to see such a process, as said above. > > For B: An advantage of the previous process was, that component > maintainers always tried to have features ready by a defined date, so > that they can become part of the full package release. However, I think > a more agile way, which allows us to release more fast and often would > be nice. It's two othre things that's good to not have too many full package releases: - developers know when things need to get done - users don't get flooded with new releases, and know when there is a full release BTW, in the past, we would also trigger a new bugfix release of a full package once in a while. I would propose that we will restrict that to security issues in the future only. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Thu, 4 Nov 2010, Tobias Schlitt wrote: > I have studied the guidelines for releases in the ASF and tried to make > up a release process document for us. Please find it attached for > discussion. You can also find it in our SVN under > > docs/release_process.txt My comments: > Component releases > == > > A component is typically maintained by a single person or a small group of > people (for simplicity, the term *maintainers* is used in following). The > maintainers of a component are in charge of proposing when a release should be > done. If the maintainers of a component decide that a release should happen, > they must choose a release manager. This choice can happen informally among > the > maintainers of a component. > > The release manager must tag the release in SVN, prepare a release package > from > this and upload it to his user space on `people.apache.org`__. He must then > call for votes on the developer mailinglist, requesting the package to be > tested by other developers. The vote must last **at least 7 days**. Every > testing developer is requested to run at least the test suite of the component > on his local system. If errors or failures occur, he is requested to vote > **-1** on the release. > > __ http://people.apache.org/ > > .. note:: Incubating phase > >After a successful vote on the developer mailinglist, the release manager >must open another vote on the Incubator PMC mailinglist for the release. >This vote must contain: > >- A reference to the RC package >- A reference to the successful developer vote >- A reference to the SVN tag for the release > > When the vote is accepted, the release manager is in charge of uploading the > release to the Apache dist server and to announce the release. > > Component releases must follow the following scheme, while each release > requires the process specified above: > > - An *alpha* release is to be held whenever a new feature has been implemented > for a component. If there are no critical issues reported within 1 week > after > officially releasing the package, the component can proceed with a *beta* > release. Otherwise, the occurred issues must be fixed before a new *alpha* > release can be rolled. > - A *beta* release is required after *alpha* stage has been completed > successfully or if the release only contains bug fixes, but no new features. > If critical issues occur 1 week after the release has been rolled, these > must > be fixed and a subsequent *beta* release must be rolled. I would also stick to what we already had here: http://incubator.apache.org/zetacomponents/community/dev_process.html#version-states > - After a successful beta stage, a stable release of the component may be > rolled. You miss here: When a release is made, the documentation should be regenerated for "latest" (which is a list of all the latest made releases from a component). Most of that stuff is documented here: http://svn.apache.org/repos/asf/incubator/zetacomponents/docs/releasing.txt > > .. note:: Determine how PEAR channel publishing can work within ASF. Proposed > is to just maintain a static PEAR channel on the main distribution > site. > > Full package release > > > A full package release does not occur as needed, but fixed dates twice a year. > > .. note:: Determine release times. I would go with "Before Christmas" and "Before the Summer holidays". > The release manager for this release is elected on the developer list through > a > vote, right after the last release has been rolled. > The full package release > does not require *alpha* and *beta* stages, since it only contains the most > recent stable releases of all components. That's a change from what we had. I would actually go with a beta period as well, where we recheck syntax and docs, and write tutorials if that's not done. > In order to roll a release, the release manager must start casting the votes > for it in the same manor as described for `Component releases`_ 2 weeks before > the release should be published. -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Documenting our coding style
On Tue, 16 Nov 2010, Tobias Schlitt wrote:
> for another project I needed to give advice on the coding standard used
> by Apache Zeta Components. There is some very old version of the eZ
> Publish coding style in [1] (from 2001) but no reliable, recent source.
> So I think we should document our coding style on the website.
>
> Please complete / correct my following brainstorming:
>
> - Indentation with 4 spaces
> - After a "{"
> - On breakup of long lines (> 78 chars) after a "("
> - "{" and "}" on a new line
> - 1 space after "(" and before ")"
> - No space after "[" and before "]"
> - 1 space after ","
> - 1 space before and after "."
> - Almost always camelCase
> - classes always start with ezc followed by an upper case char
> - constants all in upper case with "_"
There is also a script at
http://svn.apache.org/repos/asf/incubator/zetacomponents/scripts/syntax-check.sh
that has a few rough automated checks.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Location component
Hi, On Fri, Nov 26, 2010 at 7:45 AM, Christian Grobmeier wrote: > this component is currently GPL code. This is not compatible with the > AL. Will this change? > Are you the sole copyright holder for this component? Any code we submit to Zeta will of course have its copyrights transferred to ASF, and licensing changed to ASL. In cases where I'm not the sole owner we will handle the necessary CLAs with the other participants. > Christian /Henri
