Ansgar Konermann <[email protected]> wrote on 2011-08-17 04:44:41:
> From: Ansgar Konermann <[email protected]> > To: [email protected] > Date: 2011-08-17 04:46 > Subject: Re: ODF Toolkit: Existing Infrastructure > > Am 16.08.2011 17:37 schrieb "Rob Weir" <[email protected]>: > > > > On Mon, Aug 15, 2011 at 6:41 PM, Nick Burch <[email protected]> > 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. You can submit the patched to the bugzilla before we change to SVN and I will review and push. Another way, after move to SVN, you can send the patches to me, I will help you fixed it. Actually, hg can work with subversion repositories with the help of HgSubversion, a third-party tool dedicated to convenient Subversion interoperability. Please reference: http://mercurial.selenic.com/wiki/WorkingWithSubversion http://mercurial.selenic.com/wiki/HgSubversion So, please go ahead. We are looking forward to your patches ;) > > > > > > > > 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 > > >
