On Wed, 2009-10-07 at 11:24 -0700, David Brownell wrote: > On Wednesday 07 October 2009, Zach Welch wrote: > > > I think we have a plan to begin migrating and expanding the services. > > Specifically, we seem to agree upon the following actions to be done > > on Thu, Oct 8, 2009: > > > > - Disable write access to the SVN repository on BerliOS. > > - Sync GIT tree on SF.net final time, then open it for write access. > > Actually Øyvind has suggested doing that today ... "by Oct 8", if > you will. Call it 8-Oct-2009 Zulu time ... 5pm PST. :)
Yeah, I left this ambiguous to see if/how it would be clarified. :) [snip] > > - Update official GIT-over-HTTP mirror(s) of the SF repository. > > When we have such a mirror! Someone should contact SF to see > if they have a strong reason for not offering HTTP access. > > And meanwhile, folk needing HTTP access can download snapshots > using the gitweb interface at SF. I did one yesterday, it was > about 1.3MBytes (compressed TAR). At the moment, I want to see if repo.cz.or will permit mirroring using the native git protocol. I expect that supporting git:// URLs would be both easy for them and use less resources, compared to using HTTP. > > > - Update all documentation to reference the SF.net site and mirror(s). > > I've got a patch to do most of that. How about this process: > > - At time Z, commit a patch to SVN to make builds emit > a warning "current repository is <URL>" ... so that > the archival SVN history isn't trashed. > > - Also at time Z, and after syncing to the version right > before that "disable" patch, commit a patch to GIT which > makes the GIT tree reference GIT not SVN. > > - At time Z+1, both patches are upstream. Now it's safe > to make the SVN repository read-only. > > - Beginning at time Z+2, nobody uses SVN any more. Send > an email to the list finalizing that switch. > > I can handle the two commits, but can't make SVN read-only. > Zach, will you take care of that, and sending the announce? > > Where "Z" is about 5pm PST today, and values of "1" and "2" > are convenient for whoever handles those last two points. :) These sound like great ideas. I can execute my part of this plan, yes. > > - Copy all existing File Releases to SF.net. > > - Update project summary information on both sites. > > - Post an announcement that describe the changes. > > Yes. Copying the file releases can be done at any time, > as can most of the project summary info updates. IMO, do > them soon after finishing the GIT switch. Ack. I will take care of this too. > > The GIT mirror details seem to require further research, but this plan > > seems like it will move the community forward. After this first phase, > > we get into slightly-less-pressing infrastructure changes, which require > > an indeterminate amount of debate or work before being ready for action: > > > > - Debate: Migrate to another mailing list provider. Which one? > > - Debate: Should we create a new version-controlled website? How? > > - Docs: Migrate website content into repository (retire WordPress). > > - Scripting: Tag 0.3.0 in GIT and release it to SF.net and BerliOS. > > After the switch to GIT there's not a whole lot of stuff on my > personal list of "0.3.x must have". There will be URLs to change > as soon as we de-emphasize the Berlios web facilities, which may > need to be part of the 0.3.x cycle. To clarify some of my own perception of this topic, I suggest we simply begin to use SF.net as our primary development service. Since we don't like their mailing lists, we need to find a significantly better provider for that service. Since I don't see as clear winner here, it seems sensible to continue using BerliOS for now, and they can continue to provide file and documentation mirroring for us indefinitely. Rather than "moving," I see these changes as "growing", such that we seek to prevent total inaccessibility and communication breakdown. Changing to SF.net will simply change the metrics (for the better, or so we have been led to believe), but using both ensures this goal is met SVN seemed to be the biggest obstacle for developers during the outage, and we are now prepared survive such (e.g. by using GIT). SF.net can provide an "emergency contact" list, if this (or some other provider) goes down in the future. Are these in-line with your expectations? I think the talk of ditching BerliOS has been reactionary, and the idea of dropping them without a clear plan would be rash. I do not believe you were suggesting that, but I wanted to address this subject constructively and directly. > So talking in terms of an "RC" model, a week after switching to > the GIT repository seems like the a good time to want "RC1"... Again, this aligns with my thoughts on our progress, as that should also give time to finish converting the release process and script from SVN to GIT. It should be far more useful for others after the re-write too. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
