Hi,
Do we have a timeframe for when geosource will get on github? (I have gotten some questions on IRC about this).
I assume geosource is pretty close to trunk so it should not be too hard to make a branch based on the last commit merged to geosource and then merge all changes after that point onto the geosource branch.
Jesse
Hello Jesse,
2012/6/25 Jesse Eichar <jesse.eichar@anonymised.com>:
Hi,
Do we have a timeframe for when geosource will get on github? (I have
gotten some questions on IRC about this).
last version 2.7.3 [1] of GéoSource was released in April. From my side, I don’t have ongoing contract on it at the time being … but migration to github should be planned for future release for sure .
Regarding to “active” sandboxes like GéoSource or anzmest, what do you recommand ?should we fork on geonetwork organization or create a new organization on github ?
Cheers.
Francois
[1] http://www.geosource.fr/spip.php?article43
I assume geosource is pretty close to trunk so it should not be too hard to
make a branch based on the last commit merged to geosource and then merge
all changes after that point onto the geosource branch.Jesse
Do we have a timeframe for when geosource will get on github? (I have
gotten some questions on IRC about this).last version 2.7.3 [1] of GéoSource was released in April. From my side, I don’t have ongoing contract on it at the time being … but migration to github should be planned for future release for sure .
Regarding to “active” sandboxes like GéoSource or anzmest, what do you recommand ?should we fork on geonetwork organization or create a new organization on github ?
I think it depends on the community. If there is a strong community an organization can be useful as a place to congregate and focus energy. However it is easy to create a new organization and move a repository to it. I think the important thing is to get the repository to Git as soon as possible so that the new changes can be more easily merged in. However it is easy to later find the last commit merged to GeoSource and merge all changes from that point on. Essentially what you do is find the svn id of the commit. then in git do a grep on the logs for that commit and create a new branch based on that commit. Once you have the branch, copy Geosource code to git and commit. At that point you are ready to merge trunk and just fix the conflicts which hopefully is not too hard.
Jesse
On 06/26/12 07:09, Jesse Eichar wrote:
> Do we have a timeframe for when geosource will get on github? (I
have
> gotten some questions on IRC about this).last version 2.7.3 [1] of GéoSource was released in April. From my
side, I don't have ongoing contract on it at the time being ... but
migration to github should be planned for future release for sure .Regarding to "active" sandboxes like GéoSource or anzmest, what do
you recommand ?should we fork on geonetwork organization or create a
new organization on github ?I think it depends on the community. If there is a strong community an
organization can be useful as a place to congregate and focus energy.
However it is easy to create a new organization and move a repository
to it. I think the important thing is to get the repository to Git as
soon as possible so that the new changes can be more easily merged in.
However it is easy to later find the last commit merged to GeoSource
and merge all changes from that point on. Essentially what you do is
find the svn id of the commit. then in git do a grep on the logs for
that commit and create a new branch based on that commit. Once you have
the branch, copy Geosource code to git and commit. At that point you
are ready to merge trunk and just fix the conflicts which hopefully is
not too hard.
There's still no 'geosource' repo under https://github.com/geonetwork, so atm it's a bit hard for ppl wanting to build geosource 'trunk' on top of geonetwork 'trunk'. What to do, clone geonetwork git from github and svn checkout geosource subdir from sourceforge ? stay with sourceforge svn and dont get the updates from geonetwork git ? Can someone make the step of moving geosource development to git/github, for the sake of consistency ? The more we wait the harder it'll be.
http://trac.osgeo.org/geonetwork/wiki/ListOfFr is badly outdated wrt that..
Landry
Hello Landry,
2012/9/11 Landry Breuil <breuil@anonymised.com>:
On 06/26/12 07:09, Jesse Eichar wrote:
> Do we have a timeframe for when geosource will get on github? (I
have
> gotten some questions on IRC about this).last version 2.7.3 [1] of GéoSource was released in April. From my
side, I don't have ongoing contract on it at the time being ... but
migration to github should be planned for future release for sure .Regarding to "active" sandboxes like GéoSource or anzmest, what do
you recommand ?should we fork on geonetwork organization or create a
new organization on github ?I think it depends on the community. If there is a strong community an
organization can be useful as a place to congregate and focus energy.
However it is easy to create a new organization and move a repository
to it. I think the important thing is to get the repository to Git as
soon as possible so that the new changes can be more easily merged in.
However it is easy to later find the last commit merged to GeoSource
and merge all changes from that point on. Essentially what you do is
find the svn id of the commit. then in git do a grep on the logs for
that commit and create a new branch based on that commit. Once you have
the branch, copy Geosource code to git and commit. At that point you
are ready to merge trunk and just fix the conflicts which hopefully is
not too hard.There's still no 'geosource' repo under https://github.com/geonetwork,
so atm it's a bit hard for ppl wanting to build geosource 'trunk' on top
of geonetwork 'trunk'. What to do,
It depends on what is your interest but installing a geonetwork trunk
+ iso19139.fra + thesaurus provided by default in GeoSource will make
a pretty good start if you don't care about installer custom text,
default templates (you probably have your owns), logos and minor
config for the GUI.
If you have resources to make the fork and merge from last version, we
can create an organization for it.
Cheers.
Francois
clone geonetwork git from github and
svn checkout geosource subdir from sourceforge ? stay with sourceforge
svn and dont get the updates from geonetwork git ? Can someone make the
step of moving geosource development to git/github, for the sake of
consistency ? The more we wait the harder it'll be.http://trac.osgeo.org/geonetwork/wiki/ListOfFr is badly outdated wrt that..
Landry
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
On 09/11/12 18:48, Francois Prunayre wrote:
Hello Landry,
2012/9/11 Landry Breuil <breuil@anonymised.com>:
On 06/26/12 07:09, Jesse Eichar wrote:
> Do we have a timeframe for when geosource will get on github? (I
have
> gotten some questions on IRC about this).last version 2.7.3 [1] of GéoSource was released in April. From my
side, I don't have ongoing contract on it at the time being ... but
migration to github should be planned for future release for sure .Regarding to "active" sandboxes like GéoSource or anzmest, what do
you recommand ?should we fork on geonetwork organization or create a
new organization on github ?I think it depends on the community. If there is a strong community an
organization can be useful as a place to congregate and focus energy.
However it is easy to create a new organization and move a repository
to it. I think the important thing is to get the repository to Git as
soon as possible so that the new changes can be more easily merged in.
However it is easy to later find the last commit merged to GeoSource
and merge all changes from that point on. Essentially what you do is
find the svn id of the commit. then in git do a grep on the logs for
that commit and create a new branch based on that commit. Once you have
the branch, copy Geosource code to git and commit. At that point you
are ready to merge trunk and just fix the conflicts which hopefully is
not too hard.There's still no 'geosource' repo under https://github.com/geonetwork,
so atm it's a bit hard for ppl wanting to build geosource 'trunk' on top
of geonetwork 'trunk'. What to do,It depends on what is your interest but installing a geonetwork trunk
+ iso19139.fra + thesaurus provided by default in GeoSource will make
a pretty good start if you don't care about installer custom text,
default templates (you probably have your owns), logos and minor
config for the GUI.
If you have resources to make the fork and merge from last version, we
can create an organization for it.
Unfortunately i don't have the git/github skills to do that, but to me this is rather worrying as that means noone develops geosource itself anymore right now.. how will next official releases of geosource based on geonetwork 2.8.0 will be done ? Given the amount of .fr organizations that rely on geosource itself.. we can't be too much out of sync with GN.
so, to me the 'best way' to build geosource would be to :
#git clone geonetwork from github (either master or 2.8.0 branch) - will also fetch externals docs/gast/geoserver/installer/maven_repo/release
#svn checkout https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/sandbox/GeoSource/trunk geosource
remove the svn:externals from geosource svn checkout pointing to 'old' geonetwork dirs
move geosource dir under geonetwork dir
#mvn clean install -DskipTests -Penv-geosource,widgets
try to build, and pray ?
Now i'm a bit lost on where geosource should end up in the geonetwork github organisation.. should it be an external pulled by geonetwork clone, or should it be the other way round like it was done in svn (ie a geosource repo pulling geonetwork as an external) ?
Landry Breuil
On 09/12/12 10:05, Landry Breuil wrote:
On 09/11/12 18:48, Francois Prunayre wrote:
Hello Landry,
2012/9/11 Landry Breuil <breuil@anonymised.com>:
On 06/26/12 07:09, Jesse Eichar wrote:
> Do we have a timeframe for when geosource will get on
github? (I
have
> gotten some questions on IRC about this).last version 2.7.3 [1] of GéoSource was released in April. From my
side, I don't have ongoing contract on it at the time being ...
but
migration to github should be planned for future release for
sure .Regarding to "active" sandboxes like GéoSource or anzmest, what do
you recommand ?should we fork on geonetwork organization or
create a
new organization on github ?I think it depends on the community. If there is a strong community an
organization can be useful as a place to congregate and focus energy.
However it is easy to create a new organization and move a
repository
to it. I think the important thing is to get the repository to Git as
soon as possible so that the new changes can be more easily merged in.
However it is easy to later find the last commit merged to GeoSource
and merge all changes from that point on. Essentially what you do is
find the svn id of the commit. then in git do a grep on the logs for
that commit and create a new branch based on that commit. Once you
have
the branch, copy Geosource code to git and commit. At that point you
are ready to merge trunk and just fix the conflicts which hopefully is
not too hard.There's still no 'geosource' repo under https://github.com/geonetwork,
so atm it's a bit hard for ppl wanting to build geosource 'trunk' on top
of geonetwork 'trunk'. What to do,It depends on what is your interest but installing a geonetwork trunk
+ iso19139.fra + thesaurus provided by default in GeoSource will make
a pretty good start if you don't care about installer custom text,
default templates (you probably have your owns), logos and minor
config for the GUI.
If you have resources to make the fork and merge from last version, we
can create an organization for it.Unfortunately i don't have the git/github skills to do that, but to me
this is rather worrying as that means noone develops geosource itself
anymore right now.. how will next official releases of geosource based
on geonetwork 2.8.0 will be done ? Given the amount of .fr organizations
that rely on geosource itself.. we can't be too much out of sync with GN.so, to me the 'best way' to build geosource would be to :
#git clone geonetwork from github (either master or 2.8.0 branch) - will
also fetch externals docs/gast/geoserver/installer/maven_repo/release
#svn checkout
https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/sandbox/GeoSource/trunk
geosource
remove the svn:externals from geosource svn checkout pointing to 'old'
geonetwork dirs
move geosource dir under geonetwork dir
#mvn clean install -DskipTests -Penv-geosource,widgets
try to build, and pray ?Now i'm a bit lost on where geosource should end up in the geonetwork
github organisation.. should it be an external pulled by geonetwork
clone, or should it be the other way round like it was done in svn (ie a
geosource repo pulling geonetwork as an external) ?
Replying to myself, since noone seems to care atm, and i need it done @work. I've started fiddling with git/svn repos to build geosource on top of core-geonetwork 2.8.x branch, and here are my random findings :
- the diff between geonetwork and geosource can be easily made smaller (spacing/tabs, code moving around, things that could be merged from trunk..)
- it's not doable on the longterm to have geosource overwrite geonetwork files when building. it's a pain when building it, you end up with a big git diff representing the difference between pristine geonetwork and geosource. From that point, i wonder how geosource should be handled, as a fork of core-geonetwork (and its submodules), or as a git branch of core-geonetwork ? of course in both cases it'd need to regularly merging from core-geonetwork.
after all, what is geosource difference from plain geonetwork :
- web/pom.xml only adds the env-geosource profile
- shematrons/build.xml has no sensible difference
- most pom.xml set the <version> tag but that should follow the gn version
- web-client is customizing the homepage wording and the default search map layout/bbox. Most geosource end-user customize it anyway.
- web/src/main/webResources/WEB-INF/web.xml changes the displayname and changes some filters that i think should be merged back from geonetwork to reduce the diff
- iso19110 template for feature catalog is rewritten/reworded in french, this is imo gross and could probably be done as an iso19110.fra template in geonetwork itself ?
- iso19139/templates/sub-PointOfContact.xml is reworded in french and gets the some leaves of the xml tree removed (phone, country..), why ?
- web/src/main/webapp/geonetwork.css has some widget specifics class, maybe can be done in a geosource.css file instead ?
- web/src/main/webapp/xsl changes the header/homepage layout.
i didnt take into account the docs/install/release/utility changes since i only use wars and dont care about those part. i dont know the use of utility/loadContactDirAsSubTemplate_0.1.zip, maybe was used at some point for a migration between versions ?
So all those little differences could be splitted in two parts :
- the one that could be merged to core-geonetwork (i'm thinking of iso19110.fra/templates changes)
- the ui customizations specific to geosource, to be handled in a git branch/fork instead of copying files over core-geonetwork ones ?
Thx for any hints/help from geosource developers..
--
Landry Breuil
Mouton a 5 pattes du CRAIG
I am not a geosource developer but I will give you what feedback I can.
For how to handle code:
Once that is done I would copy the configuration file and iso profiles to the fork, then test :). If there are any major code changes I would make a fork off of the master branch add those changes to that branch and try to contribute them back to Geonetwork. To do that you need to do the normal proposal process unless the change is minor, in which case you can just make a pull request.
Once you have the “feature” branch you can merge that feature branch onto your geosource branch. You want the feature on its own branch so that it can be easily merged back on to trunk.
The one problem with this solution is that it makes it very tempting to make more changes to core-geonetwork and allow geosource to diverge from core-geonetwork. Probably even better would be to make a new git repository with only the geosource files. It could be a maven project with a dependency on geonetwork-main project and is overlays the geosource files on the geonetwork-main war.
If you have time to do that I think it would be better.
Jesse
On Tue, Oct 2, 2012 at 11:14 AM, Landry Breuil <breuil@anonymised.com> wrote:
On 09/12/12 10:05, Landry Breuil wrote:
On 09/11/12 18:48, Francois Prunayre wrote:
Hello Landry,
2012/9/11 Landry Breuil <breuil@anonymised.com>:
On 06/26/12 07:09, Jesse Eichar wrote:
Do we have a timeframe for when geosource will get on
github? (I
have
gotten some questions on IRC about this).last version 2.7.3 [1] of GéoSource was released in April. From my
side, I don’t have ongoing contract on it at the time being …
but
migration to github should be planned for future release for
sure .Regarding to “active” sandboxes like GéoSource or anzmest, what do
you recommand ?should we fork on geonetwork organization or
create a
new organization on github ?I think it depends on the community. If there is a strong community an
organization can be useful as a place to congregate and focus energy.
However it is easy to create a new organization and move a
repository
to it. I think the important thing is to get the repository to Git as
soon as possible so that the new changes can be more easily merged in.
However it is easy to later find the last commit merged to GeoSource
and merge all changes from that point on. Essentially what you do is
find the svn id of the commit. then in git do a grep on the logs for
that commit and create a new branch based on that commit. Once you
have
the branch, copy Geosource code to git and commit. At that point you
are ready to merge trunk and just fix the conflicts which hopefully is
not too hard.There’s still no ‘geosource’ repo under https://github.com/geonetwork,
so atm it’s a bit hard for ppl wanting to build geosource ‘trunk’ on top
of geonetwork ‘trunk’. What to do,It depends on what is your interest but installing a geonetwork trunk
- iso19139.fra + thesaurus provided by default in GeoSource will make
a pretty good start if you don’t care about installer custom text,
default templates (you probably have your owns), logos and minor
config for the GUI.
If you have resources to make the fork and merge from last version, we
can create an organization for it.Unfortunately i don’t have the git/github skills to do that, but to me
this is rather worrying as that means noone develops geosource itself
anymore right now… how will next official releases of geosource based
on geonetwork 2.8.0 will be done ? Given the amount of .fr organizations
that rely on geosource itself… we can’t be too much out of sync with GN.so, to me the ‘best way’ to build geosource would be to :
#git clone geonetwork from github (either master or 2.8.0 branch) - will
also fetch externals docs/gast/geoserver/installer/maven_repo/release
#svn checkout
https://geonetwork.svn.sourceforge.net/svnroot/geonetwork/sandbox/GeoSource/trunk
geosource
remove the svn:externals from geosource svn checkout pointing to ‘old’
geonetwork dirs
move geosource dir under geonetwork dir
#mvn clean install -DskipTests -Penv-geosource,widgets
try to build, and pray ?Now i’m a bit lost on where geosource should end up in the geonetwork
github organisation… should it be an external pulled by geonetwork
clone, or should it be the other way round like it was done in svn (ie a
geosource repo pulling geonetwork as an external) ?Replying to myself, since noone seems to care atm, and i need it done
@work. I’ve started fiddling with git/svn repos to build geosource on
top of core-geonetwork 2.8.x branch, and here are my random findings :
- the diff between geonetwork and geosource can be easily made smaller
(spacing/tabs, code moving around, things that could be merged from trunk…)- it’s not doable on the longterm to have geosource overwrite geonetwork
files when building. it’s a pain when building it, you end up with a big
git diff representing the difference between pristine geonetwork and
geosource. From that point, i wonder how geosource should be handled, as
a fork of core-geonetwork (and its submodules), or as a git branch of
core-geonetwork ? of course in both cases it’d need to regularly merging
from core-geonetwork.after all, what is geosource difference from plain geonetwork :
- web/pom.xml only adds the env-geosource profile
- shematrons/build.xml has no sensible difference
- most pom.xml set the tag but that should follow the gn
version- web-client is customizing the homepage wording and the default
search map layout/bbox. Most geosource end-user customize it anyway.- web/src/main/webResources/WEB-INF/web.xml changes the displayname
and changes some filters that i think should be merged back from
geonetwork to reduce the diff- iso19110 template for feature catalog is rewritten/reworded in
french, this is imo gross and could probably be done as an iso19110.fra
template in geonetwork itself ?- iso19139/templates/sub-PointOfContact.xml is reworded in french and
gets the some leaves of the xml tree removed (phone, country…), why ?- web/src/main/webapp/geonetwork.css has some widget specifics class,
maybe can be done in a geosource.css file instead ?- web/src/main/webapp/xsl changes the header/homepage layout.
i didnt take into account the docs/install/release/utility changes since
i only use wars and dont care about those part. i dont know the use of
utility/loadContactDirAsSubTemplate_0.1.zip, maybe was used at some
point for a migration between versions ?So all those little differences could be splitted in two parts :
- the one that could be merged to core-geonetwork (i’m thinking of
iso19110.fra/templates changes)- the ui customizations specific to geosource, to be handled in a git
branch/fork instead of copying files over core-geonetwork ones ?Thx for any hints/help from geosource developers…
–
Landry Breuil
Mouton a 5 pattes du CRAIG
Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork