atom feed11 messages in migration plan from
FromSent OnAttachments
Kohsuke KawaguchiOct 6, 2009 3:53 pm 
Andrew BayerOct 6, 2009 4:03 pm 
Edelson, JustinOct 6, 2009 4:05 pm 
Edelson, JustinOct 6, 2009 4:10 pm 
Michael DonohueOct 6, 2009 7:56 pm 
Andrew BayerOct 6, 2009 8:07 pm 
Stephen ConnollyOct 6, 2009 10:42 pm 
Edelson, JustinOct 7, 2009 6:09 am 
Mirko FriedenhagenOct 7, 2009 2:47 pm 
Kohsuke KawaguchiOct 7, 2009 3:14 pm 
Kohsuke KawaguchiOct 8, 2009 5:29 pm 
Subject:Revised migration plan from
From:Kohsuke Kawaguchi (Kohs@Sun.COM)
Date:Oct 6, 2009 3:53:56 pm

Thanks for various feedbacks to the "migration from" thread.

- I noted that several suggestions to take the project to Apache, and several suggestions not to. In any case, Apache doesn't work for us because of the requirement to donate the code to ASF, and that wouldn't make sense at people making that decision. Our complaint is "look, we have no reliable hosting infrastructure", and I don't see how saying that "we solve the problem by donating the code to Apache" flies.

- I continue to receive e-mails about people unable to access Hudson website. So moving the project front page and associated downloads to seems like the highest priority.

- I noted that most are concerned about the issue tracker primarily, and I didn't hear a lot of complaints about the Subversion repository. So I'm pushing down Subversion migration further down the list.

So based on that, slightly modified and bit more detailed migration plan is, in the order of importance:

- Move the project website to This is a server we own and manage, so we can control the cache related headers and other things. Start advertising this address instead of

- Downloads and update center metadata from, mirrored from the Maven repository. This is a highly-available clustered servers that Sun uses for everything from Solaris to JDK, NetBeans to OpenOffice. (I'm still working on details)

- Host bug tracker on that we run by ourselves, by using JIRA license that we have.

- Move Subversion repository to Kenai, if the availability problem persists.

In addition, Andrew Bayer and I've done some research on some of the technical details:

- Migration of Subversion repository turns out to be very easy.

- we clone the repo to Kenai via svnsync. The initial sync will take a few hours. - On flag day, we do the incremental sync, then make one final commit to SVN to remove trunk, to avoid accidental commits. - People can run "svn switch --relocate" to point their workspace to a new repo. - Several POMs need to be rewritten to keep the maven release plugin happy.

- Details on is still being investigated.

- I've developed a custom plugin for Atlassian Crowd so that one can use the same identity between Wiki, JIRA, and This would help in smoother issue tracker migration, and fend off spams.

- abayer continues to work on the technical feasibility of the issue tracker migration.

- The goal is to migrate all the issues with comments, attachments, etc., with their issue numbers intact. - JIRA will use the same user ID and password as - HTTP redirector to redirect URLs like to for minimum disruption

- I'm working inside Sun to allocate additional internet-facing systems to host the new services, in a way that lets community participate in the administration/management.