incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ansgar Konermann <ansgar.konerm...@googlemail.com>
Subject Re: ODF Toolkit: Existing Infrastructure
Date Tue, 16 Aug 2011 20:44:41 GMT
Am 16.08.2011 17:37 schrieb "Rob Weir" <apache@robweir.com>:
>
> 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

Apache announced initial support for git a week ago or so, at least for beta
usage. As git is very similar to hg (dvcs), we should really push ASF to
allow odf toolkit to pilot git usage. I'm convinced a dvcs will facilitate
contributing to odftoolkit a lot, so please let's at least *try* to get a
dvcs right from the start.

I know two of my co workers have a number of patches ready for contribution
to simple api, but going back to svn will likely distract them.

> >
>
> 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/
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message