On Wednesday, 27 March 2013 at 4:45 AM, Wayne Beaton wrote:
The answer to the question regarding versioning is entirely up to
the project; you know your community.
Some other responses in line.
Wayne
On 03/26/2013 03:35 AM, Frank Gasdorf
wrote:
forwarded to udig-developer list to
discuss about the next steps..
WIth
the 1.4.0 tag in place we are likely to vanish
from the face of the internet as we switch
repositories, only to emerge renewed after an IP
check.
not sure weather its a good idea to
re-release with the same Version number after IP check
is done. IMHO we need a clear cut - for users and
developers - to emphasize something has changed. In
addition I assume we have to change the code basis
during IP check -process (changed dependencies, changing
headers again, etc.) that the current release is based
on something else (we don't know at the moment) and
therefor I would prefer to re-release with a different
version number.
Whether
we should increase the minor or major version it's not
that important. I would be fine with a 1.5/1.4.1 or even
2.0.
To
start going through the IP we are taking the current
release tag 1.4.0. Seem that we do not transfer the whole
history as a git repository, which is fine as long as we
have the chance to set the current repo at github
read-only.
From the LocationTech POV, this isn't necessary. I recommend that
you include a CONTRIBUTING file in the root of the repository to
give anybody who clones it a fighting chance of figuring out how to
find the new location.
FWIW, it's entirely acceptable to clone your locationtech.org
repository on GitHub.
With
this in mind, I've the following questions:
- How
do we handle changes on master once the IP process has
been started? (e.g. set it read-only and announce this on
udig-developer mailing list)
The initial stage of the review of the project's initial
contribution should go fairly quickly. It should only take a couple
of days to get provisional check-in approval. What I recommend that
you do is tag the existing repo at the point where you export the
initial contribution. Any commits following that point can be pushed
into the locationtech.org repository in consideration of the IP due
diligence process. In short, if the commits are authored by project
committers, just push them. If they come from outside contributors,
there's a little more involved.
It's probably a good idea to ask your mentors for help the first
time you need to accept an outside contribution.
- What
about the community repository, do we migrate it as well
or leave it where it is?
Is the community repository part of the project? Assuming that the
contents of the "community repository" are in scope, you can migrate
it now or at some point in the future.
This contribution will most likely require review by the IP team. We
can discuss this in detail if you'd like.
- Which docs from the udig-docs repository are in question
to move to LocationTech as well? (user/devel as well as
the walkthrough's (except uDigWalkthrough3.odt) we already
migrated to udig-platform/docs. Afterwards we can set this
repository to read-only as well, can't we?
If it helps Frank, those eclipse pages
indicate they are willing to phone your employer
and answer questions.
WIth the 1.4.0 tag in place we are likely to
vanish from the face of the internet as we
switch repositories, only to emerge renewed
after an IP check.
--
Jody Garnett
On Friday,
15 March 2013 at 8:33 PM, Frank Gasdorf
wrote:
Benjamin, Jody,
thanks for your support. I've
already filled out everything and
just waiting to get "Eclipse
Committer Employer Consent Form"
signed from my managing Director.
Hope to get the signature till end
of next week. After that I'll send
a fax to Eclipse foundation.
Using you Eclipse
Bugzilla
credentials, you
should login to http://portal.eclipse.org/ .
From there, you
should be able to
fill-in the
committer
questionnaire.
The answer to the question regarding versioning is entirely up to
the project; you know your community.
Some other responses in line.
Wayne
On 03/26/2013 03:35 AM, Frank Gasdorf
wrote:
forwarded to udig-developer list to
discuss about the next steps..
WIth
the 1.4.0 tag in place we are likely to vanish
from the face of the internet as we switch
repositories, only to emerge renewed after an IP
check.
not sure weather its a good idea to
re-release with the same Version number after IP check
is done. IMHO we need a clear cut - for users and
developers - to emphasize something has changed. In
addition I assume we have to change the code basis
during IP check -process (changed dependencies, changing
headers again, etc.) that the current release is based
on something else (we don't know at the moment) and
therefor I would prefer to re-release with a different
version number.
Whether
we should increase the minor or major version it's not
that important. I would be fine with a 1.5/1.4.1 or even
2.0.
To
start going through the IP we are taking the current
release tag 1.4.0. Seem that we do not transfer the whole
history as a git repository, which is fine as long as we
have the chance to set the current repo at github
read-only.
From the LocationTech POV, this isn't necessary. I recommend that
you include a CONTRIBUTING file in the root of the repository to
give anybody who clones it a fighting chance of figuring out how to
find the new location.
FWIW, it's entirely acceptable to clone your locationtech.org
repository on GitHub.
With
this in mind, I've the following questions:
- How
do we handle changes on master once the IP process has
been started? (e.g. set it read-only and announce this on
udig-developer mailing list)
The initial stage of the review of the project's initial
contribution should go fairly quickly. It should only take a couple
of days to get provisional check-in approval. What I recommend that
you do is tag the existing repo at the point where you export the
initial contribution. Any commits following that point can be pushed
into the locationtech.org repository in consideration of the IP due
diligence process. In short, if the commits are authored by project
committers, just push them. If they come from outside contributors,
there's a little more involved.
It's probably a good idea to ask your mentors for help the first
time you need to accept an outside contribution.
- What
about the community repository, do we migrate it as well
or leave it where it is?
Is the community repository part of the project? Assuming that the
contents of the "community repository" are in scope, you can migrate
it now or at some point in the future.
This contribution will most likely require review by the IP team. We
can discuss this in detail if you'd like.
- Which docs from the udig-docs repository are in question
to move to LocationTech as well? (user/devel as well as
the walkthrough's (except uDigWalkthrough3.odt) we already
migrated to udig-platform/docs. Afterwards we can set this
repository to read-only as well, can't we?
If it helps Frank, those eclipse pages
indicate they are willing to phone your employer
and answer questions.
WIth the 1.4.0 tag in place we are likely to
vanish from the face of the internet as we
switch repositories, only to emerge renewed
after an IP check.
--
Jody Garnett
On Friday,
15 March 2013 at 8:33 PM, Frank Gasdorf
wrote:
Benjamin, Jody,
thanks for your support. I've
already filled out everything and
just waiting to get "Eclipse
Committer Employer Consent Form"
signed from my managing Director.
Hope to get the signature till end
of next week. After that I'll send
a fax to Eclipse foundation.
Using you Eclipse
Bugzilla
credentials, you
should login to http://portal.eclipse.org/ .
From there, you
should be able to
fill-in the
committer
questionnaire.