Martin Desruisseaux wrote:
Jody Garnett a écrit :
martin you are starting to run a couple urls associated with geotools,
and I am have not seen them anywhere on the wiki?
I am placing them on development for now, but we will need more
guidance and perhaps a plan?
The geotools.fr namespace was supposed to be merily resources for french
developpers, especially students, because we realized that the language
barrier was a significant difficulty for some of them. My hope was to
get maven.geotools.org to point toward maven.geotools.fr, so we can
"hide" the geotools.fr namespace for most developpers (and allows James
to change server if he wish). But we need James intervention for that.
My proposal is:
maven.geotools.org --> maven.geotools.fr Maven repository and
reports.
javadoc.geotools.org --> javadoc.geotools.fr Javadoc for 2.2 and
2.3 branchs.
www.geotools.fr Place for resources
in French.
No redirection
toward that one.
No development and no mailing list would occurs on www.geotools.fr.
www.geotools.org would stay the only central place for development and
mailing lists. I do not plan to maintain www.geotools.fr myself (this is
managed by somebody else). My energy will still focused on geotools.org.
I posted an email (with some discretion I admit) about www.geotools.fr
in January, asking if it were okay to create such name space. I didn't
got any feedback at that time, but I guess that it still possible to
rollback if it is an issue...
This sounds great, I'm all for GeoTools in other languages. I have one
concern with adopting maven and javadoc locations at geotools.fr, which
is can all developers upload there? Or at least all PMC/release
managers? It's bad if you are the only one who can upload Martin, we
want there to be as few bottlenecks as possible.
lists.refractions.net/dist works nicely now, since all svn committers
automatically have access. It might be easier to just get a
geotools.org redirection to there? I for one am also fine with just
leaving it as lists.refractions.net, as a nice service that refractions
provides where they can get a slight bit of PR for their support,
providing maven build distributions. For javadocs I do think we should
try to get them under a geotools domain though. But it could make a lot
of sense to but the javadocs and the maven jars in the same place, so
each release gets both of them up.
best regards,
Chris
Here is the updated page, I think we should ask some of the old guard
(Ian, James, Martin) to provide some guidance
on how we should be interacting with SF facilities or codehaus
facilities.
We have a space for web pages (http://geotools.sourceforge.net/) which
is currently unused. There is also a bug tracker (unused since we use
JIRA), news (unusued since we use CodeHaust), space for screenshot,
mailing list (mailing list and download area are the only SourceForge
services that we use right now as far as I know), space for
documentation (completly outdated), etc.
Actually, bug tracker and some other services are still used for
Geotools 1. What should we do with them? Is Geotools 1 still in
development? Or should we close (hide) all bug trackers on SourceForge?
Martin.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
