Topics

Moving to Java EE Github?


Will Hopkins
 

I think I'm about ready to migrate the repos to the javaee organization.

If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

The plan is to migrate as follows:
  • security-spec -> javaee/security-spec
    • issues are already there (migrated from java.net)
    • migrate the source only, using git clone
    • recreate releases based on migrated tags at the destination
    • will lose pull-request history, but should preserve everything else we need.
git clone --bare $GITHUB_URL_OLD_REPO
cd <repo-name>.git
git push --mirror $GITHUB_URL_NEW_REPO
  • security-api -> javaee/security-api
    • use github "transfer" function to migrate entire repo
  • soteria -> javaee/security-ri-soteria
    • use github "transfer function to migrate  entire repo
    • rename repo when transfer completes

I'll make a full (bare) clone of each repo before transferring it.

Seem like a reasonable plan?

Will




On 07/11/2017 02:21 PM, Werner Keil wrote:
Ok, let us know, if you need any help by those who have the necessary rights.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Ok, let us know, if you need any help by those who have the necessary rights.


Will Hopkins
 

I plan to move them asap, hopefully this week.

On 07/11/2017 08:40 AM, Werner Keil wrote:
Since Java EE 8 does not reference anything other than the JCP detail page of JSR 375 we should be OK to move e.g. after PFD went out.

The Spec with https://github.com/javaee-security-spec/security-spec (which has a history of several branches and release tags) and https://github.com/javaee/security-spec which has the entire JIRA history from java.net seems the most tricky part. Somehow we need to find a compromise between the codebase and issues. IMO both are equally important.

With enough Git experience and the right credentials, it should be possible to import all of https://github.com/javaee-security-spec/security-spec
into https://github.com/javaee/security-spec without losing any branch. The javaee repo only has "gh-pages" so "master" or any other branch and tags should be possible to import without having to delete either of the repos. And after it's succesful, the old one can be deleted. 

All other repositories probably best change ownerwhip if Will or somebody else at Oracle can transfer ownership between both organizations.

Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Since Java EE 8 does not reference anything other than the JCP detail page of JSR 375 we should be OK to move e.g. after PFD went out.

The Spec with https://github.com/javaee-security-spec/security-spec (which has a history of several branches and release tags) and https://github.com/javaee/security-spec which has the entire JIRA history from java.net seems the most tricky part. Somehow we need to find a compromise between the codebase and issues. IMO both are equally important.

With enough Git experience and the right credentials, it should be possible to import all of https://github.com/javaee-security-spec/security-spec
into https://github.com/javaee/security-spec without losing any branch. The javaee repo only has "gh-pages" so "master" or any other branch and tags should be possible to import without having to delete either of the repos. And after it's succesful, the old one can be deleted. 

All other repositories probably best change ownerwhip if Will or somebody else at Oracle can transfer ownership between both organizations.

Regards,
Werner


Werner Keil
 

Now as the Public Review Ballot is about to close (almost everyone voted, and it looks quite good, no "Jigsaw situation";-) how about moving the relevant repositories soon?

The git remote command based approach is unlikely to move any of the GitHub issues, so for those the entire repository would have to change ownership to a new organization from all I know.

There is one important point,
https://github.com/javaee/security-spec/
already has all the issues which look like they came from java.net:
https://github.com/javaee/security-spec/issues

So this repo MUST NOT be deleted there!
Seems the gh-pages branch is the only one created by default when it migrated from java.net, so the owner or a user with sufficient admin rights should be able to create a new "master" branch and copy all the Asciidoc content over from https://github.com/javaee-security-spec/security-spec

https://github.com/javaee-security-spec/security-api has no issue tracker enabled, so it could be migrated either way, whether it is "git remote", transfer ownership or copying content into a new empty repository.

Soteria https://github.com/javaee-security-spec/soteria has quite a few issues, many still open, so for it migrating it in a way that takes those issues over sounds best. To my knowledge it can only be done if the user has full admin or owner rights in the new organization. For the other two repositories it could be possible for someone with push rights, depending on whether or not they can create branches or not. 

The example repository should be preserved in some place, either with JavaEE or in a different organization/project. Then potentially the organization could be taken down. If someone keeps the "sandbox" as drafts or notes, with the JSR well advanced now, most of the plausible ideas are on their way.

Werner


Will Hopkins
 

Sounds like moving the source will be fairly straightforward using push, and that would allow us to keep mirrors for a little while until we were sure of the transition.

Is there a similar way to move the issues, though, or will that have to be done programattically?

On 07/05/2017 02:04 PM, Ivar Grimstad wrote:
Hi Will,

It should be fairly risk free to move between organizations. You will, as Werner said, have to remove the existing javaee/security-spec repo to be able to do it. 
Another way is  to simply add the javaee/security-spec repo as a remote, typically

`git remote add javaee git@...:javaee/security-spec.git`

Then make sure you have pulled the latest from the existing repo before pushing. Beware that you may need to pull from javaee first and merge since there have been some changes done there that are not in the security-spec organization repo. You will also most likely have some conflicts with files present in both repos (CONTRIBUTING, README, LICENCE etc). Do a dry run first with the -n option to check...
Or you could do a push with force:

`git push javaee master --force`

This is how we did it with the MVC spec. The difference there is that we treat our mvc-spec organization as the master and treat javaee as a read-only mirror. I guess you will want to have it the other way round.

Are you planning to use the security-spec organization for anything, or remove it when everything has been moved to javaee?

Ivar

On Wed, Jul 5, 2017 at 6:51 PM Will Hopkins <will.hopkins@...> wrote:
Is that something you tried when migrating other JSRs? My chief concern is a catastrophic failure (loss of the repo or some part of it) if the transfer doesn't go through, due to permissions problems, or because there's something different about the javaee organization compared to other organizations at github (because it's a corporate org).

Will


On 07/05/2017 11:14 AM, Werner Keil wrote:
If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
--

Java Champion, JCP EC/EG Member, JUG Leader


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

>Are you planning to use the security-spec organization for anything, or remove it when everything has been moved to javaee?

Currently at least the CI (Travis) runs against the existing repos. If the repo moves, the CI needs access again, but given the current access rights situation I'm not sure if that would be feasible.

Then again, everyone can set up a mirror and run a CI against that, so this should not be a blocker, just something to keep in mind.



On Wed, Jul 5, 2017 at 8:04 PM, Ivar Grimstad <ivar.grimstad@...> wrote:
Hi Will,

It should be fairly risk free to move between organizations. You will, as Werner said, have to remove the existing javaee/security-spec repo to be able to do it. 
Another way is  to simply add the javaee/security-spec repo as a remote, typically

`git remote add javaee git@...:javaee/security-spec.git`

Then make sure you have pulled the latest from the existing repo before pushing. Beware that you may need to pull from javaee first and merge since there have been some changes done there that are not in the security-spec organization repo. You will also most likely have some conflicts with files present in both repos (CONTRIBUTING, README, LICENCE etc). Do a dry run first with the -n option to check...
Or you could do a push with force:

`git push javaee master --force`

This is how we did it with the MVC spec. The difference there is that we treat our mvc-spec organization as the master and treat javaee as a read-only mirror. I guess you will want to have it the other way round.

Are you planning to use the security-spec organization for anything, or remove it when everything has been moved to javaee?

Ivar

On Wed, Jul 5, 2017 at 6:51 PM Will Hopkins <will.hopkins@...> wrote:
Is that something you tried when migrating other JSRs? My chief concern is a catastrophic failure (loss of the repo or some part of it) if the transfer doesn't go through, due to permissions problems, or because there's something different about the javaee organization compared to other organizations at github (because it's a corporate org).

Will


On 07/05/2017 11:14 AM, Werner Keil wrote:
If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
--

Java Champion, JCP EC/EG Member, JUG Leader



Ivar Grimstad
 

Hi Will,

It should be fairly risk free to move between organizations. You will, as Werner said, have to remove the existing javaee/security-spec repo to be able to do it. 
Another way is  to simply add the javaee/security-spec repo as a remote, typically

`git remote add javaee git@...:javaee/security-spec.git`

Then make sure you have pulled the latest from the existing repo before pushing. Beware that you may need to pull from javaee first and merge since there have been some changes done there that are not in the security-spec organization repo. You will also most likely have some conflicts with files present in both repos (CONTRIBUTING, README, LICENCE etc). Do a dry run first with the -n option to check...
Or you could do a push with force:

`git push javaee master --force`

This is how we did it with the MVC spec. The difference there is that we treat our mvc-spec organization as the master and treat javaee as a read-only mirror. I guess you will want to have it the other way round.

Are you planning to use the security-spec organization for anything, or remove it when everything has been moved to javaee?

Ivar

On Wed, Jul 5, 2017 at 6:51 PM Will Hopkins <will.hopkins@...> wrote:
Is that something you tried when migrating other JSRs? My chief concern is a catastrophic failure (loss of the repo or some part of it) if the transfer doesn't go through, due to permissions problems, or because there's something different about the javaee organization compared to other organizations at github (because it's a corporate org).

Will


On 07/05/2017 11:14 AM, Werner Keil wrote:
If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

--

Java Champion, JCP EC/EG Member, JUG Leader


Arjan Tijms
 

I share Will's concern a little here. Perhaps a copy instead of transfer is saver. Keep the existing repos as a mirror (in the title of the repos, clearly notice it are mirrors).

When after some time the mirror is not needed anymore we can delete it.

Kind regards,
Arjan Tijms


Will Hopkins
 

Is that something you tried when migrating other JSRs? My chief concern is a catastrophic failure (loss of the repo or some part of it) if the transfer doesn't go through, due to permissions problems, or because there's something different about the javaee organization compared to other organizations at github (because it's a corporate org).

Will

On 07/05/2017 11:14 AM, Werner Keil wrote:
If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

If a repository doesn't exist in the new organization under the same name and the user who tries to do it is at least admin of both (not sure, if ownership is needed and who has ownership of the JavaEE organization?) it should work.


Will Hopkins
 

Either way, I think your assistance would be helpful.

Do you happen to know whether the "move" capability in GitHub, which allows a repo to be transferred from one organization to another will work? That would probably be the safest way to move while preserving issues and all the history. For the "security-spec" repo, the java.net issues have been migrated to security-spec under the javaee organization already, so for that repo we might need to use clone, but I'd want someone more experienced with git to verify the correct procedure to preserve all the commit history, branches, labels, etc.

Thanks,

Will

On 07/03/2017 04:24 PM, Will Hopkins wrote:
What do you think about moving it after the PFD is published?

On 07/03/2017 05:08 AM, Werner Keil wrote:
Hi,

At least before Proposed Final Draft I was wondering, if a move to the official GitHub organization for Java EE https://github.com/javaee was planned any time soon?
If it isn't done now, then most likely all documents including the Spec etc. will have to refer to the existing GitHub organization and that needs to remain until e.g. a new Security JSR (follow up to 375) arises at some later point.

Moving it after it went Final would be confusing. So let's either try to do this now, or stay there till another JSR comes up for Security under Java EE 9 or later.

I assisted most of this transition for JSR 374 (JSON-P) so happy to help if given the right credentials and ability. I'm sure, others like Rudy or Arjan are equally happy to to help if Will and his colleagues at Oracle are busy with other duties or things only they can do at the moment (like writing the TCK;-)

Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

What do you think about moving it after the PFD is published?

On 07/03/2017 05:08 AM, Werner Keil wrote:
Hi,

At least before Proposed Final Draft I was wondering, if a move to the official GitHub organization for Java EE https://github.com/javaee was planned any time soon?
If it isn't done now, then most likely all documents including the Spec etc. will have to refer to the existing GitHub organization and that needs to remain until e.g. a new Security JSR (follow up to 375) arises at some later point.

Moving it after it went Final would be confusing. So let's either try to do this now, or stay there till another JSR comes up for Security under Java EE 9 or later.

I assisted most of this transition for JSR 374 (JSON-P) so happy to help if given the right credentials and ability. I'm sure, others like Rudy or Arjan are equally happy to to help if Will and his colleagues at Oracle are busy with other duties or things only they can do at the moment (like writing the TCK;-)

Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Hi,

At least before Proposed Final Draft I was wondering, if a move to the official GitHub organization for Java EE https://github.com/javaee was planned any time soon?
If it isn't done now, then most likely all documents including the Spec etc. will have to refer to the existing GitHub organization and that needs to remain until e.g. a new Security JSR (follow up to 375) arises at some later point.

Moving it after it went Final would be confusing. So let's either try to do this now, or stay there till another JSR comes up for Security under Java EE 9 or later.

I assisted most of this transition for JSR 374 (JSON-P) so happy to help if given the right credentials and ability. I'm sure, others like Rudy or Arjan are equally happy to to help if Will and his colleagues at Oracle are busy with other duties or things only they can do at the moment (like writing the TCK;-)

Kind Regards,
Werner