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.