Re: Call for help in DarwinPorts Transition to MacOSForge
James Berry <[email protected]>
| Newsgroups | gmane.os.opendarwin.darwinports |
|---|---|
| Message-ID | <[email protected]> |
On Aug 8, 2006, at 8:10 AM, Jordi S. Bunster wrote: >> Who can volunteer to help us through this transition? > > I can. :) So far I've heard a strong response both from Jordi and from Chris Ridd (who will be on vacation for a couple of weeks). Alright! Way to step up to the plate! And it's still early in the morning (here). I should mention that we may need additional help in translations. > So it is: > > 1. The home page, which has news and news archives, plus it is > written in many languages. > > I would agree that WordPress is a good fit for this, more so than > Trac. It will provide news archiving, time-based RSS feeds, and as > far as multiple languages go, one of these should suffice: http:// > codex.wordpress.org/Plugins/Translation_and_Languages Okay, that's good feedback > 2. The DarwinPorts Guide > > I would love to see the XML for this, to see what I can do about > automatic migration onto Trac. Would the goal be to create > something like this: http://trac.edgewall.org/wiki/TracGuide? Or is > it to lose all structure and go full wiki, with lots of pages with > descriptive titles? Edgewall themselves seem to use a hybrid > approach, they have the aforelinked guide, but also lost of other > pages in that wiki. See http://trac.edgewall.org/wiki/TitleIndex. The xml is in cvs, at doc/guide. > 3. http://wiki.opendarwin.org/index.php/Category:DarwinPorts > > If this is all that the wiki is, I would vote to merge this content > onto whatever the result of migrating item 2 is. > > 4. Bugzilla > > Hopefully this helps: http://trac.edgewall.org/browser/trunk/ > contrib/bugzilla2trac.py Yes, thanks, I've seen that: it will undoubtedly come in handy > 5. Subversion > > As you mention, cvs -> subversion should not be that complicated. > The only time I've heard of problems with this, is on very large > trees that make the migration script run out of memory. > I could start with the guide as soon as you folks decide on the > details. I think the thing to do for right now (the next day or so, anyway) is planning and investigation. The folks at Apple who are handling macosforge are understandably a bit overwhelmed by tasks at WWDC. We're still waiting for them to get a project and some accounts set up. But as far as the details of how the docs should get moved over, I think that's up to you guys, at least for a recommendation. The guidelines I'd like to see: - Easy to change, by members of a broader community where possible. - Multi-language is a plus, though probably not a drop-dead issue - Simple is always good. Reorganizing the existing material to make it easier to find/follow/update, is good. - We should look carefully at where dynamic pages are used/needed (for instance, port descriptions) and come up with a strategy for handling that. Such materials might even live on a separate box somewhere. One thing that would be useful on the planning front is to understand what WordPress or Trac plugins or modules we might want in addition to the standard installation; these might take some lead time to get going, and we should get our requests in to the macosforge folks sooner rather than later. James