On Tue, Aug 16, 2011 at 4:44 PM, Ansgar Konermann <[email protected]> wrote: > 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. >
Where did you see this announcement? > 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 >> > >
