You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2018/06/11 20:23:25 UTC
Migration from SVN to Git in progress
Hello all
The git repository has been created [1], so the SVN repository should be
considered read-only now. We still have to do the history cleanup as
proposed in [2], then the new Git URL will be available for push operations.
Martin
[1] https://issues.apache.org/jira/browse/INFRA-16577
[2] https://lists.apache.org/thread.html/60324c4f631fee3add288988f5813a81725ab7145541cd0c946e1204@%3Cdev.sis.apache.org%3E
Re: git push --force applied, next step proposal
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Oh, sorry, actually said that it relates to snapshots, meaning that developers would recognize that as the latest too. Not that it could confuse developers.
Either way is OK for me (and all in all, every alternative we had here sounds better than JDK8 :). Up to you.
Looking forward to working with SIS code base in git!
Thanks again for taking care of this Martin!
Bruno
________________________________
From: Martin Desruisseaux <ma...@geomatys.com>
To: dev@sis.apache.org
Sent: Friday, 15 June 2018 9:00 PM
Subject: Re: git push --force applied, next step proposal
Le 15/06/2018 à 10:27, Bruno P. Kinoshita a écrit :
>> "geoapi-latest" is a nice idea. Or maybe "geoapi-snapshot" for
>> avoiding confusion with "latest release"?
>>
> I like both :) And geoapi-snapshot probably relates to Maven snapshots.
>
Indeed it relates to Maven snapshots. I think that Gradle uses the same?
But it is true that we may not always use snapshots in the future (e.g.
we could use timestamp for more stability), so after a second though
"geoapi-latest" seems safer…
Thanks for the feedback!
Martin
Re: git push --force applied, next step proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 15/06/2018 à 10:27, Bruno P. Kinoshita a écrit :
>> "geoapi-latest" is a nice idea. Or maybe "geoapi-snapshot" for
>> avoiding confusion with "latest release"?
>>
> I like both :) And geoapi-snapshot probably relates to Maven snapshots.
>
Indeed it relates to Maven snapshots. I think that Gradle uses the same?
But it is true that we may not always use snapshots in the future (e.g.
we could use timestamp for more stability), so after a second though
"geoapi-latest" seems safer…
Thanks for the feedback!
Martin
Re: git push --force applied, next step proposal
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
>"geoapi-latest" is a nice idea. Or maybe "geoapi-snapshot" for avoiding
>confusion with "latest release"?
I like both :) And geoapi-snapshot probably relates to Maven snapshots.
________________________________
From: Martin Desruisseaux <ma...@geomatys.com>
To: dev@sis.apache.org
Sent: Friday, 15 June 2018 7:50 PM
Subject: Re: git push --force applied, next step proposal
Le 15/06/2018 à 09:20, Bruno P. Kinoshita a écrit :
> So I think the development branch, which was JDK8 before, could also
> be called geoapi-compatibility, or geoapi-latest.
>
"geoapi-latest" is a nice idea. Or maybe "geoapi-snapshot" for avoiding
confusion with "latest release"?
> I think in the future if others ask about it, maybe just adding a note about it in the Developer Guide, or somewhere else in the site documentation, would be enough.
http://sis.apache.org/branches.html tries to explain that, but I agree
that this is confusing. I will edit those pages after the branches
rearrangement.
Martin
Re: git push --force applied, next step proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 15/06/2018 à 09:20, Bruno P. Kinoshita a écrit :
> So I think the development branch, which was JDK8 before, could also
> be called geoapi-compatibility, or geoapi-latest.
>
"geoapi-latest" is a nice idea. Or maybe "geoapi-snapshot" for avoiding
confusion with "latest release"?
> I think in the future if others ask about it, maybe just adding a note about it in the Developer Guide, or somewhere else in the site documentation, would be enough.
http://sis.apache.org/branches.html tries to explain that, but I agree
that this is confusing. I will edit those pages after the branches
rearrangement.
Martin
Re: git push --force applied, next step proposal
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Hi Martin,
So I think the development branch, which was JDK8 before, could also be called geoapi-compatibility, or geoapi-latest.
I think in the future if others ask about it, maybe just adding a note about it in the Developer Guide, or somewhere else in the site documentation, would be enough.
Thanks for clarifying!
Bruno
________________________________
From: Martin Desruisseaux <ma...@geomatys.com>
To: dev@sis.apache.org
Sent: Friday, 15 June 2018 1:38 AM
Subject: Re: git push --force applied, next step proposal
Hello Bruno
Thanks for the feedback!
Le 14/06/2018 à 14:50, Bruno P. Kinoshita a écrit :
> Minor nit-pick, what's the rationale behind master & development?
>
The "development" branch uses GeoAPI methods or interfaces that are not
yet in the official GeoAPI release. This serves two purposes:
* Verify that the interfaces proposed for next GeoAPI releases work.
* Be ready to upgrade easily to next GeoAPI versions after its release.
But the Apache releases can not depend on a GeoAPI 4.0-SNAPSHOT. We need
to downgrade to GeoAPI 3.0.1 (until a new GeoAPI release is available).
This downgrade is applied on "master", which is the branch from which
Apache SIS releases are made.
The fact that "master" is more stable is just a side-effect of above,
since "development" get the day-to-day commits and "master" only get the
backports a few time per months. But we can try other development models
too if there is proposal.
Martin
Re: git push --force applied, next step proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Bruno
Thanks for the feedback!
Le 14/06/2018 à 14:50, Bruno P. Kinoshita a écrit :
> Minor nit-pick, what's the rationale behind master & development?
>
The "development" branch uses GeoAPI methods or interfaces that are not
yet in the official GeoAPI release. This serves two purposes:
* Verify that the interfaces proposed for next GeoAPI releases work.
* Be ready to upgrade easily to next GeoAPI versions after its release.
But the Apache releases can not depend on a GeoAPI 4.0-SNAPSHOT. We need
to downgrade to GeoAPI 3.0.1 (until a new GeoAPI release is available).
This downgrade is applied on "master", which is the branch from which
Apache SIS releases are made.
The fact that "master" is more stable is just a side-effect of above,
since "development" get the day-to-day commits and "master" only get the
backports a few time per months. But we can try other development models
too if there is proposal.
Martin
Re: git push --force applied, next step proposal
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
+1 to all
Minor nit-pick, what's the rationale behind master & development?
Couldn't we assume the latest tag contains the release most stable API? And anything after that, regardless of which branch, is development and there's no guarantee about stability?
And +1 for renaming from JDK8. development is thousand times better than JDK.
Cheers
Bruno
________________________________
From: Martin Desruisseaux <ma...@geomatys.com>
To: dev@sis.apache.org
Sent: Friday, 15 June 2018 12:37 AM
Subject: git push --force applied, next step proposal
Hello all
A new "git push --force" has just been applied on
https://gitbox.apache.org/repos/asf/sis.git with removal of files listed
in SIS and INFRA tasks [1][2]. All removed files are still available on
SVN. The large ones that were not backup files are in the data directory
[3]. Starting from now, there will be hopefully no more history rewrite.
For next steps, I propose to apply the following additional cleanup:
* Delete the following tags:
o 0.2-incubating
o 0.2-incubating-rc2
o 0.2-incubating-rc3
* Rename the following tag:
o 0.2-incubating-rc4 → 0.2-incubating
* Delete the following branches (if we really need to start from an
old release, we can start from the tag):
o 0.1-incubating
o 0.2-incubating
o 0.3
o 0.4
o 0.5
o 0.6
o 0.7
o 0.8
* Rename the following branch:
o JDK8 → development
After those changes, the main branches would be:
* development: were day-to-day commits are done. Depends on GeoAPI
4.0-SNAPSHOT.
* master: the most stable branch. Depends on GeoAPI 3.0.1 official
release.
Any comment, objection, amendment?
Martin
[1] https://issues.apache.org/jira/browse/SIS-422
[2] https://issues.apache.org/jira/browse/INFRA-16577
[3] https://svn.apache.org/repos/asf/sis/data/unclassified/
Re: Proposed development branch: geoapi-4.0
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 19/06/2018 à 22:22, Bruno P. Kinoshita a écrit :
> And as I'm still learning by readind docs and code, will report/update
> docs that need to be updated.
>
Thanks! Speaking about reading documentation, there is two sources that
I found valuable:
For the model behind following packages:
* org.opengis.metadata
* org.apache.sis.metadata.iso
I recommend the NOAA wiki:
https://geo-ide.noaa.gov/wiki/index.php?title=Category:ISO_19115
I found it useful because the ISO standard just gives a succinct
description of each element. It is sometime hard to guess how we are
supposed to use them. The NOAA wiki explains in more details: the
purpose, best practice, etc.
For the model behind following packages:
* org.opengis.referencing
* org.apache.sis.referencing
I recommend OGC topic 2, "Spatial referencing by coordinates", in
particular annex B, "Context for modelling of spatial referencing by
coordinates" and annex C, "Geodetic concepts":
http://portal.opengeospatial.org/files/?artifact_id=39049
Those two annexes help to understand why Coordinate Reference System
classes are designed that way, why apparently simple solutions like
using WGS 84 as a universal pivot does not work, etc.
Regards,
Martin
Re: Proposed development branch: geoapi-4.0
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 20/06/2018 à 15:18, Bruno P. Kinoshita a écrit :
> (…) having the tags in SVN only, as well as the new tags in git is OK
> for me.
>
I rebased the last 3 tags (0.6, 0.7, 0.8). Rebasing older tags would
have been more work, so I deleted them and would rather put a note
somewhere referring to SVN history. Anyway, I'm tempted to delete all
"pre-migration" tags after 1.0 release since I'm not 100% sure that they
are correct (only the SVN tags are sure).
Removing old references has apparently reduced git repository size by
about 20% compared to the size before this pruning effort.
Martin
Re: Proposed development branch: geoapi-4.0
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
As I am learning Apache SIS for a project, and not really interested about older releases (maybe the current stable only?), having the tags in SVN only, as well as the new tags in git is OK for me.
Not sure about other users, but if developer/contributor bandwidth is restricted, perhaps just leave a note somewhere in the project docs pointing to the SVN tags, and/or put a ticket in JIRA maybe for some day?
CheersBruno
From: Martin Desruisseaux <ma...@geomatys.com>
To: dev@sis.apache.org
Sent: Wednesday, 20 June 2018 9:38 PM
Subject: Re: Proposed development branch: geoapi-4.0
Le 19/06/2018 à 22:22, Bruno P. Kinoshita a écrit :
> And I'm OK wih the removal of other branches. My real interest is on
> the development version, and tags only.
>
Branches removed from Git repository (still available on SVN). JDK9
branch has been re-created but is not for day-to-day development (until
all modularization issues have been resolved).
About the tags on Git: they are still referencing the old history. It
could be fixed, but this would require some work. Is it sufficient to
said that all tags prior SIS 1.0 should be fetched from SVN, or do we
need those tags on Git too?
Martin
Re: Proposed development branch: geoapi-4.0
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 19/06/2018 à 22:22, Bruno P. Kinoshita a écrit :
> And I'm OK wih the removal of other branches. My real interest is on
> the development version, and tags only.
>
Branches removed from Git repository (still available on SVN). JDK9
branch has been re-created but is not for day-to-day development (until
all modularization issues have been resolved).
About the tags on Git: they are still referencing the old history. It
could be fixed, but this would require some work. Is it sufficient to
said that all tags prior SIS 1.0 should be fetched from SVN, or do we
need those tags on Git too?
Martin
Re: Proposed development branch: geoapi-4.0
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
+1 to geoapi-4.0
And I'm OK wih the removal of other branches. My real interest is on the development version, and tags only.
And as I'm still learning by readind docs and code, will report/update docs that need to be updated.
Thanks!Bruno
Sent from Yahoo Mail on Android
On Wed, 20 Jun 2018 at 5:07, Martin Desruisseaux<ma...@geomatys.com> wrote: Hello all
Following on the discussion about what could be the name of the
development branch (formerly "JDK8"), I propose "geoapi-4.0", for
consistency with another branch named "geoapi-3.1". More details on
those two branches are given there:
http://sis.staging.apache.org/branches.html
I'm tempted to delete the other branches since they are stalled and
should not be used for more development (in part because of the Git
history rewrite, but also because SIS has evolved since the last commit
on those branches). Those branches are still available on Subversion; if
their development restart, we would probably have to port the code to
latest commit on the development branch anyway.
Is there any comment or thing that we should change? I think that master
history can not be changed anymore, but for everything else it is still
time to change before the development resumes that normal speed.
Martin
Proposed development branch: geoapi-4.0
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello all
Following on the discussion about what could be the name of the
development branch (formerly "JDK8"), I propose "geoapi-4.0", for
consistency with another branch named "geoapi-3.1". More details on
those two branches are given there:
http://sis.staging.apache.org/branches.html
I'm tempted to delete the other branches since they are stalled and
should not be used for more development (in part because of the Git
history rewrite, but also because SIS has evolved since the last commit
on those branches). Those branches are still available on Subversion; if
their development restart, we would probably have to port the code to
latest commit on the development branch anyway.
Is there any comment or thing that we should change? I think that master
history can not be changed anymore, but for everything else it is still
time to change before the development resumes that normal speed.
Martin
git push --force applied, next step proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello all
A new "git push --force" has just been applied on
https://gitbox.apache.org/repos/asf/sis.git with removal of files listed
in SIS and INFRA tasks [1][2]. All removed files are still available on
SVN. The large ones that were not backup files are in the data directory
[3]. Starting from now, there will be hopefully no more history rewrite.
For next steps, I propose to apply the following additional cleanup:
* Delete the following tags:
o 0.2-incubating
o 0.2-incubating-rc2
o 0.2-incubating-rc3
* Rename the following tag:
o 0.2-incubating-rc4 → 0.2-incubating
* Delete the following branches (if we really need to start from an
old release, we can start from the tag):
o 0.1-incubating
o 0.2-incubating
o 0.3
o 0.4
o 0.5
o 0.6
o 0.7
o 0.8
* Rename the following branch:
o JDK8 → development
After those changes, the main branches would be:
* development: were day-to-day commits are done. Depends on GeoAPI
4.0-SNAPSHOT.
* master: the most stable branch. Depends on GeoAPI 3.0.1 official
release.
Any comment, objection, amendment?
Martin
[1] https://issues.apache.org/jira/browse/SIS-422
[2] https://issues.apache.org/jira/browse/INFRA-16577
[3] https://svn.apache.org/repos/asf/sis/data/unclassified/
Re: Migration from SVN to Git in progress
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello all
The following files has been removed from Git repository:
* California_Restaurants.csv
* DEPARTEMENT.SHP
* ANC90Ply_4326.shp
* build-impl.xml~ (a backup file)
As announced, this caused a rewrite of git history. The next few days I
will do more checks for verifying that everything is okay and post a new
email when the repository can be considered stable.
Thanks
Martin