Re: migration stuff, wiki page
Go up one page from the "Site PPMC Plan": https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning That page is trying to collect all the plans together, not to duplicate the planning effort. We should probably add a link to "site transition" from the "Site PPMC Plan" if we want to have both pages. Or merge them into one page. I don't have a strong preference. -Rob On Fri, Jun 24, 2011 at 10:23 AM, Raphael Bircher wrote: > > I agree with that but I don't understand what's the difference between "site > transition" and "Site PPMC Plan" > > Is Site PPMC Plan for organisation? "Site transiting" sounds like al the > technical stuff we need for the migration. > > Greetings Raphael > > > -- > My private Homepage: http://www.raphaelbircher.ch/ >
Re: migration stuff, wiki page
Am 24.06.11 16:07, schrieb Rob Weir: I think the plan happens on several levels. At one level it is the survey of existing OOo website resources, how active they are, what licenses they are covered by, what formats they are in. That is the survey level. Then we need a proposal for how those resources map into the Apache infrastructure. This could be high level, like Hg -> SVN, Bugzilla -> Bugzilla, etc. Then we need an execution plan. This is going to require the coordination of Apache OpenOffice.org volunteers, Apache Infrastructure, volunteers from the legacy OpenOffice website and Oracle IT personal. We want to transfer the soup without spilling it. A top level decision will be whether we do this incrementally, system, by system, or whether we need to do a "big bang" migration. For example, an incremental approach might say that we migrate over the defect tracker in one week: 0) Back up existing bug tracking database. 1) Project volunteer does trial migration on their own server, to verify that the process can go smoothly. Make the instance available to the Apache project for testing/verification. Document the steps needed, any special settings, workarounds, required patches, etc. Iterate until the test migration works reliably. 2) Agree on a date to do the real migration. At that time, kock the defect tracker in the legacy OOo site to prevent updates. Put notice on that site that we are in the process of migrating. 3) Working with Apache Infrastructure, do the real migration, using any special instructions documented in step 1. Keep the Apache instance of the defect tracker read-only except for project members, until we've tested and verified that it is working properly, 4) Once we've agreed that the new instance is working correctly, get the admin of the legacy OOo website to do a redirect of requests to the legacy OOo defect tracker to the Apache instance. 5) Enable public access to Apache instance 6) Pray. I agree with that but I don't understand what's the difference between "site transition" and "Site PPMC Plan" Is Site PPMC Plan for organisation? "Site transiting" sounds like al the technical stuff we need for the migration. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: migration stuff, wiki page
I think the plan happens on several levels. At one level it is the survey of existing OOo website resources, how active they are, what licenses they are covered by, what formats they are in. That is the survey level. Then we need a proposal for how those resources map into the Apache infrastructure. This could be high level, like Hg -> SVN, Bugzilla -> Bugzilla, etc. Then we need an execution plan. This is going to require the coordination of Apache OpenOffice.org volunteers, Apache Infrastructure, volunteers from the legacy OpenOffice website and Oracle IT personal. We want to transfer the soup without spilling it. A top level decision will be whether we do this incrementally, system, by system, or whether we need to do a "big bang" migration. For example, an incremental approach might say that we migrate over the defect tracker in one week: 0) Back up existing bug tracking database. 1) Project volunteer does trial migration on their own server, to verify that the process can go smoothly. Make the instance available to the Apache project for testing/verification. Document the steps needed, any special settings, workarounds, required patches, etc. Iterate until the test migration works reliably. 2) Agree on a date to do the real migration. At that time, kock the defect tracker in the legacy OOo site to prevent updates. Put notice on that site that we are in the process of migrating. 3) Working with Apache Infrastructure, do the real migration, using any special instructions documented in step 1. Keep the Apache instance of the defect tracker read-only except for project members, until we've tested and verified that it is working properly, 4) Once we've agreed that the new instance is working correctly, get the admin of the legacy OOo website to do a redirect of requests to the legacy OOo defect tracker to the Apache instance. 5) Enable public access to Apache instance 6) Pray. That is the incremental approach. It is a lot of steps, but I think we want something like this in order to ensure continuity of the services to the end users. The "big bang" approach, as you might imagine, tries to do all of these services in a short period of time, like over a weekend. It is much harder and stressful. I'd recommend the incremental. So again, I see the transition plan as requiring a survey of existing services, a proposal for where those services are mapped to the Apache infrastructure and then an execution plan for each service. -Rob On Fri, Jun 24, 2011 at 8:23 AM, Raphael Bircher wrote: > Hi at all > > For preparation of the big migration we plane to make same thing similar as > http://kenai.com/projects/ooo-migration/pages/Home unfortunaly we have three > space for it atm. We should reduce them to one. > > https://cwiki.apache.org/confluence/display/OOODEV/Infrastructure > I think, the developer wiki is not the ideal place for it. OOODEV request a > singed ICLA. But at the migration we have to collaborate with people who > don't have a singed ICLA e.g. like Kenai Admins from Oracle. So IMHO it's > better to use the USER wiki for it. > > At the User Wiki we have two top sits: > > https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan > > and > > https://cwiki.apache.org/confluence/display/OOOUSERS/Transition+Planning > > Can sameone explain the difference between the two site. For my point of > view we should concentrate the efforts to one top page and his subpages. > > What do you think about. > > Greetings Raphael > -- > My private Homepage: http://www.raphaelbircher.ch/ >
Re: migration stuff, wiki page
Raphael Bircher wrote: > Hi at all > > For preparation of the big migration we plane to make same thing similar > as http://kenai.com/projects/ooo-migration/pages/Home unfortunaly we > have three space for it atm. We should reduce them to one. > > https://cwiki.apache.org/confluence/display/OOODEV/Infrastructure > I think, the developer wiki is not the ideal place for it. OOODEV > request a singed ICLA. But at the migration we have to collaborate with > people who don't have a singed ICLA e.g. like Kenai Admins from Oracle. > So IMHO it's better to use the USER wiki for it. > > At the User Wiki we have two top sits: > > https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan > > and > > https://cwiki.apache.org/confluence/display/OOOUSERS/Transition+Planning Speaking for myself, this seem to be the logical location. > Can sameone explain the difference between the two site. For my point of > view we should concentrate the efforts to one top page and his subpages. > > What do you think about. > > Greetings Raphael Andy
