incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: ODF Toolkit: Existing Infrastructure
Date Thu, 18 Aug 2011 00:53:07 GMT

On Aug 16, 2011, at 8:16 AM, Rob Weir wrote:

> On Mon, Aug 15, 2011 at 6:41 PM, Nick Burch <nick.burch@alfresco.com> wrote:
>> On Mon, 15 Aug 2011, Rob Weir wrote:
>>> 
>>> 1)  a wiki (no idea what application this is underneath -- might be
>>> specific to Kenai)
>> 
>> Do you know what syntax it supports? If you can get a page listing the
>> syntax, I'd suggest comparing it against the confluence one, the moinmoin
>> one, and markdown
>> 
> 
> Syntax is here:  http://odftoolkit.org/projects/help/pages/Wikis#Wiki_Formatting
> 
> Looks like this is MediaWiki.
> 
>>> 6) A Mercurial repository
>> 
>> This will need to be switched to SVN, with an read only git repo available
>> too. No reason why people can't use the hg svn integration to keep working
>> on hg locally if they want to, but SVN will need to be the canonical store
>> 
> 
> Right.  Ideally we want to preserve history.  I'm not sure what is
> possible here.  This will require some experiments with Hg -> Svn
> conversions.  This can be done locally until we have a dump file for
> Svn we can hand off to Apache Infra.
> 
>> 
>>> ODFDOM and the Conformance tools use the wiki has its primary home
>>> page.   Simple JavaAPI uses the wiki for release notes, but has a
>>> separate main home page.
>> 
>> I'd suggest we try to convert the bulk of these into regular markdown pages.
>> Switching the wiki syntax should be pretty easy.
>> 
> 
> Wiki pages probably migrate easily.  Not so sure of the Simple API
> pages, which may require more formatting control that markdown offers:
> 
> http://simple.odftoolkit.org/

We can wrap the html within the Apache CMS and the Bookmarklet will allow the html to be edited.

We can pass html directly

What are the plans for odftoolkit.org?

odftookit.org is registered by Oracle at TuCows like OOo. 

For the incubator these would typically be transformed as follows:

odfdom.odftoolkit.org => incubator.apache.org/odftoolkit/odfdom/
simple.odftoolkit.org => incubator.apache.org/odftoolkit/simple/
www.odftoolkit.org => incubator.apache.org/odftoolkit or incubator.apache.org/odftoolkit/www

Does this make sense?

Regards,
Dave

> 
> I know something about the Apache CMS and markdown from the Apache
> OpenOffice project.  But for those who are not familiar it, we have
> the option of maintaining our website using text files in "markdown"
> syntax.[1].  This is simpler than HTML, more like wiki text.  But you
> can drop down into HTML when needed, and the styling is done via CSS.
> 
> The markdown files are stored in SVN and can be checked out and edited
> and committed like any other file.  But Apache also has a web-based
> system where you can edit the markdown pages in your browser, with a
> WYSIWYG preview.  This makes it very easy for any project committer to
> edit the web pages.
> 
> More information here [2], this is also an example of a page created
> in markdown.
> 
> 
> [1] http://daringfireball.net/projects/markdown/syntax
> [2] http://incubator.apache.org/openofficeorg/docs/edit-cms.html
> 
> 
>> Wikis are best for things that non committers may wish to help with, for the
>> official docs it's probably best to put it in the CMS
>> 
>>> ODFDOM and the Conformance tools doe not have user forums.   Simple
>>> API does, but they are not really used.  The user mailing list is
>>> where the main engagement with users occurs.
>> 
>> OK, I'd suggest we try to close it to make things easier
>> 
>>> There are around 400 total issues in Bugzilla (in all states) and
>>> maybe 40 wiki pages.
>> 
>> Do you know which version of bugzilla, and if a dump is possible?
>> 
> 
> It is Bugzilla 3.2.10.  I don't have permissions to create a dump.
> Svante?  Daisy?  It is possible we'll need to put in a request with
> the Kenai admins at Oracle for this.
> 
>> 
>>> I'd like to see if we can try to think of this as a single project,
>>> with a single home page (of course, with detailed pages for each
>>> component), with a user user list, single dev list, single repository,
>>> etc.
>> 
>> That would make sense to me. If we find a lot of traffic on the user list,
>> we can always split it later into the sub-projects. To start with it's
>> probably best to have one list to help build the community
>> 
>>> The amount of content is not very much.  So worst case, we could migrate
>>> the wiki with cut & paste.
>> 
>> A small perl script can usually help with translating the syntax :)
>> 
> 
> I'm faster with cut & paste than with perl.  But python is another story...
> 
>> Nick
>> 


Mime
View raw message