Re: Website
Personally, I think forest is the right thing to do regarding product documentation (manuals, api docs, user docs). It very version specific and needs to stay with the source code. That said, project information is NOT product or version specific. The general website could get generated from the WIKI. And I think it's a better medium to use since editing a wiki page is easier to do than updating svn and then generating a site. I too would be willing to help. And I think we can take it in stages. We could easily migrate what you have today in MoinMoin to confluence. Then we could provide the value add of skining those wiki pages so that have the same look and feel that the main site uses that way the main site and wiki look more integrated. Once that is setup, I'm sure you guys will be more comfortable with the process and more information from the main site could get migrated over to the wiki. On Wed, Jul 23, 2008 at 2:15 PM, James Strachan <[EMAIL PROTECTED]> wrote: > 2008/7/23 Doug Cutting <[EMAIL PROTECTED]>: >> James Strachan wrote: >>> >>> Tools like wikis are personal things; and folks tend to prefer to use >>> the tool they know. >> >> That's a key point. >> >> To make a switch you'd need: >> 1. Someone familiar with Confluence to lead the transition, convert the >> existing website and wiki content, set up static export etc. Are you >> volunteering? > > I would yes, but only if 2) gets approval. > >> 2. Buy in from Zookeeper's primary contributors, who will end up writing >> and maintaining the documentation (Pat, Ben, etc.). I don't really count, >> since I'm mostly a kibitzer here. >> >> Also, with Confluence export, how does one deal with versioning? A >> convenience of keeping documentation in subversion is that it gets versioned >> with releases. By maintaining the trunk documentation to match the trunk >> implementation, we automatically get documentation that matches each >> version, but we can still maintain the documentation in release branches. I >> don't see how this would not add overhead with Confluence exports. If >> Confluence always represented trunk, and we exported at release branch >> points, then it would be hard to patch branched documentation. Maintaining >> multiple branches in Confluence would add management overhead, since these >> would need to be synchronized with subversion branching, tagging, etc. How >> have other projects dealt with this issue? > > BTW MoinMoin has the same issue; when documentation is in the wiki you > need to grab a snapshot of it to include in releases (or add it to > svn) to support versioned documentation. > > What we've done in the past is copy the static HTML from the wiki with > releases; or in some projects we turn the HTML from Confluence into a > proper manual in PDF or HTML format. e.g. > > if you download 1.4.0 of Camel.. > http://activemq.apache.org/camel/camel-140-release.html > > and look in the docs directory; you'll see a manual in PDF and HTML > format. Thats generated from the wiki whenever there is a release from > these pages > http://activemq.apache.org/camel/book.html > which include various wiki pages together to form a user manual. > > which are then included together in this page > http://activemq.apache.org/camel/book-in-one-page.html > > > Maybe moving away from Forrest is a step too far right now; but its > certainly worth thinking whether for the wiki content its gonna be > MoinMoin or Confluence. Only if you choose Confluence then you can > consider generating a user manual or the static website from it > (neither AFAIK are possible with MoinMoin). > > > Incidentally a totally different thought; whats gonna be the split > between whats the static website (e.g. Forrest) versus stuff thats in > the wiki versus documentation that goes inside each release? Its often > a kinda slippery slope figuring out which bit does what and its a PITA > moving content into different formats to move between them; so while > no tool is perfect, I kinda like that with confluence there's just one > place to put docs and you can then slice and dice as you see fit (and > make multiple spaces if you want & share content across spaces) to > deal with different version issues etc. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
Re: Website
James Strachan wrote: Incidentally a totally different thought; whats gonna be the split between whats the static website (e.g. Forrest) versus stuff thats in the wiki versus documentation that goes inside each release? Its often a kinda slippery slope figuring out which bit does what Official documentation for end-users is in subversion (Forrest). This is vetted by the release process. Un-official, typically user-generated documentation whose accuracy, copyright, etc. is not guaranteed by the project goes in the wiki. The wiki is also used for some developer documentation that is not intended for end users, e.g., HowToRelease, HowToContribute, etc. These could migrate into the project's official website (repos/asf/hadoop/zookeeper/site) if we like. and its a PITA moving content into different formats to move between them; so while no tool is perfect, I kinda like that with confluence there's just one place to put docs and you can then slice and dice as you see fit Sure, it would be convenient if these were all in a common format, but, as mentioned before, Confluence would make it harder to manage branched documentation. Doug
Re: Website
2008/7/23 Doug Cutting <[EMAIL PROTECTED]>: > James Strachan wrote: >> >> Tools like wikis are personal things; and folks tend to prefer to use >> the tool they know. > > That's a key point. > > To make a switch you'd need: > 1. Someone familiar with Confluence to lead the transition, convert the > existing website and wiki content, set up static export etc. Are you > volunteering? I would yes, but only if 2) gets approval. > 2. Buy in from Zookeeper's primary contributors, who will end up writing > and maintaining the documentation (Pat, Ben, etc.). I don't really count, > since I'm mostly a kibitzer here. > > Also, with Confluence export, how does one deal with versioning? A > convenience of keeping documentation in subversion is that it gets versioned > with releases. By maintaining the trunk documentation to match the trunk > implementation, we automatically get documentation that matches each > version, but we can still maintain the documentation in release branches. I > don't see how this would not add overhead with Confluence exports. If > Confluence always represented trunk, and we exported at release branch > points, then it would be hard to patch branched documentation. Maintaining > multiple branches in Confluence would add management overhead, since these > would need to be synchronized with subversion branching, tagging, etc. How > have other projects dealt with this issue? BTW MoinMoin has the same issue; when documentation is in the wiki you need to grab a snapshot of it to include in releases (or add it to svn) to support versioned documentation. What we've done in the past is copy the static HTML from the wiki with releases; or in some projects we turn the HTML from Confluence into a proper manual in PDF or HTML format. e.g. if you download 1.4.0 of Camel.. http://activemq.apache.org/camel/camel-140-release.html and look in the docs directory; you'll see a manual in PDF and HTML format. Thats generated from the wiki whenever there is a release from these pages http://activemq.apache.org/camel/book.html which include various wiki pages together to form a user manual. which are then included together in this page http://activemq.apache.org/camel/book-in-one-page.html Maybe moving away from Forrest is a step too far right now; but its certainly worth thinking whether for the wiki content its gonna be MoinMoin or Confluence. Only if you choose Confluence then you can consider generating a user manual or the static website from it (neither AFAIK are possible with MoinMoin). Incidentally a totally different thought; whats gonna be the split between whats the static website (e.g. Forrest) versus stuff thats in the wiki versus documentation that goes inside each release? Its often a kinda slippery slope figuring out which bit does what and its a PITA moving content into different formats to move between them; so while no tool is perfect, I kinda like that with confluence there's just one place to put docs and you can then slice and dice as you see fit (and make multiple spaces if you want & share content across spaces) to deal with different version issues etc. -- James --- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
Re: Website
Regardless of which wiki we use the documentation is in Forrest and checked into SVN. Forrest is used both to write the docs (which are versioned along with the code) as well as generating the hadoop.apache.org web site. (trunk/src/docs) We have a tech writer who is currently migrating the sourceforge documentation to forrest. The wiki will be used to capture information which is specifically not documentation; faq, policies, procedures, etc... Patrick Doug Cutting wrote: James Strachan wrote: Tools like wikis are personal things; and folks tend to prefer to use the tool they know. That's a key point. To make a switch you'd need: 1. Someone familiar with Confluence to lead the transition, convert the existing website and wiki content, set up static export etc. Are you volunteering? 2. Buy in from Zookeeper's primary contributors, who will end up writing and maintaining the documentation (Pat, Ben, etc.). I don't really count, since I'm mostly a kibitzer here. Also, with Confluence export, how does one deal with versioning? A convenience of keeping documentation in subversion is that it gets versioned with releases. By maintaining the trunk documentation to match the trunk implementation, we automatically get documentation that matches each version, but we can still maintain the documentation in release branches. I don't see how this would not add overhead with Confluence exports. If Confluence always represented trunk, and we exported at release branch points, then it would be hard to patch branched documentation. Maintaining multiple branches in Confluence would add management overhead, since these would need to be synchronized with subversion branching, tagging, etc. How have other projects dealt with this issue? Doug
Re: Website
James Strachan wrote: Tools like wikis are personal things; and folks tend to prefer to use the tool they know. That's a key point. To make a switch you'd need: 1. Someone familiar with Confluence to lead the transition, convert the existing website and wiki content, set up static export etc. Are you volunteering? 2. Buy in from Zookeeper's primary contributors, who will end up writing and maintaining the documentation (Pat, Ben, etc.). I don't really count, since I'm mostly a kibitzer here. Also, with Confluence export, how does one deal with versioning? A convenience of keeping documentation in subversion is that it gets versioned with releases. By maintaining the trunk documentation to match the trunk implementation, we automatically get documentation that matches each version, but we can still maintain the documentation in release branches. I don't see how this would not add overhead with Confluence exports. If Confluence always represented trunk, and we exported at release branch points, then it would be hard to patch branched documentation. Maintaining multiple branches in Confluence would add management overhead, since these would need to be synchronized with subversion branching, tagging, etc. How have other projects dealt with this issue? Doug
Re: Website
Best bet is to put it to the vote - create a Jira. I'll make sure we get input from Hadoop PMC and core team members. Patrick James Strachan wrote: 2008/7/22 Hiram Chirino <[EMAIL PROTECTED]>: Lol.. Apache infrastructure supports multiple wiki backends. It's up to the project to pick which one you want to you. You currently have picked MoinMoin, but you could have easily picked Confluence, just like these other Apache projects did: http://cwiki.apache.org/confluence/dashboard.action FWIW I've been on plenty of apache projects that started on MoinMoin, then realised down the line how much better Confluence is - then went through the wiki migration pain. Tools like wikis are personal things; and folks tend to prefer to use the tool they know. But its worth seriously thinking about which wiki you want up front - before you realise down the line that you wanna switch. Just because the rest of hadoop uses MoinMoin doesn't mean you have to follow suit; all wikis can link to each other nicely. And there might be some hadoop folks who are not exactly head over heals about MoinMoin. All I'm gonna say is I've used both heavily and far prefer Confluence hands down; it means you can avoid all the Forest stuff; Confluence can auto-export its content to make a rather nice static HTML site for you; keeping your website and wiki clean, updated and fresh. Plus you can then reuse the same wiki markup inside your issue tracker (JIRA) - so you don't need to remember multiple wiki formats. Finally, there's great JIRA macros in confluence for creating lovely release notes in your website; or the snippet macros to link to fragments of test cases in your online documentation (so your documentation gets unit tested). Having said all that - its up to you guys to pick something you're happy with - so I'll bow out now and leave you to it :)
Re: Website
2008/7/22 Hiram Chirino <[EMAIL PROTECTED]>: > Lol.. Apache infrastructure supports multiple wiki backends. It's up > to the project to pick which one you want to you. You currently have > picked MoinMoin, but you could have easily picked Confluence, just > like these other Apache projects did: > > http://cwiki.apache.org/confluence/dashboard.action FWIW I've been on plenty of apache projects that started on MoinMoin, then realised down the line how much better Confluence is - then went through the wiki migration pain. Tools like wikis are personal things; and folks tend to prefer to use the tool they know. But its worth seriously thinking about which wiki you want up front - before you realise down the line that you wanna switch. Just because the rest of hadoop uses MoinMoin doesn't mean you have to follow suit; all wikis can link to each other nicely. And there might be some hadoop folks who are not exactly head over heals about MoinMoin. All I'm gonna say is I've used both heavily and far prefer Confluence hands down; it means you can avoid all the Forest stuff; Confluence can auto-export its content to make a rather nice static HTML site for you; keeping your website and wiki clean, updated and fresh. Plus you can then reuse the same wiki markup inside your issue tracker (JIRA) - so you don't need to remember multiple wiki formats. Finally, there's great JIRA macros in confluence for creating lovely release notes in your website; or the snippet macros to link to fragments of test cases in your online documentation (so your documentation gets unit tested). Having said all that - its up to you guys to pick something you're happy with - so I'll bow out now and leave you to it :) -- James --- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
Re: Website
Lol.. Apache infrastructure supports multiple wiki backends. It's up to the project to pick which one you want to you. You currently have picked MoinMoin, but you could have easily picked Confluence, just like these other Apache projects did: http://cwiki.apache.org/confluence/dashboard.action Regards, Hiram On Tue, Jul 22, 2008 at 4:25 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > The Hadoop project, including ZooKeeper, is currently using the Apache wiki. > There are no plans at this time to use confluence: > > http://wiki.apache.org/hadoop/ZooKeeper > > Patrick > > > Hiram Chirino wrote: >> >> On Tue, Jul 22, 2008 at 2:54 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: >>> >>> I cloned core/hbase subprojects, so we do what's currently done by other >>> hadoop subs. The issue has come up in the past, might be a good idea at >>> some >>> point but might also add even more complexity to already pretty complex >>> process (see howtorelease page). I think we should get things setup >>> similar >>> to existing subs (still alot of work to be done converting the wiki over >>> to >>> apache wiki/docs) and review at some point in the future. >>> >>> Howtocontrib/howtorelease/faq is already on the wiki: >>> http://wiki.apache.org/hadoop/ZooKeeper >>> >>> mailinglists/news/etc... are part of the docs (not wiki), probably more >>> convention than anything. mailinglist never changes and I believe news >>> (and >>> prolly some others) is part of docs in order to be versioned, but also to >>> enable users who have checked out the code to have direct access . >>> >> >> That's cool too.. If you are going to use a Wiki it might be better to >> use the confluence one just cause it can easily be skinned to have the >> main site's look and feel. Plus it has a bunch of cool macros >> available to import code examples from svn or bring in a table of >> issues from JIRA (for example >> http://openejb.apache.org/ejb-3-roadmap.html ) etc. >> >> Regards, >> Hiram >> >>> Patrick >>> >>> Hiram Chirino wrote: On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > > Hi Hiram, see ZOOKEEPER-70 & 72. We'll be following Hadoop core/hbase > wrt > the docs/site/wiki. Specifically using Apache Forrest for the > documentation, > which also generates the site. We're in the process of moving the > sourceforge wiki content over from SF to apache. > > I'm been working with a couple of the hadoop core team members getting > their > input re the site, I had actually planned to push something live today. > > Additional complexity is due to the fact that on SF we had all docs on > the > wiki and were not including the api docs in the release. Apache > requires > us > to version our documentation proper along with the code (so has to be > in > SVN > and not on the wiki) and we also have to include the api docs (as well > as > regular docs) along with each release which we are not doing on SF. Yep. BTW you can still take a hybrid approach where the general site information (stuff like how to contirbute, mailing lists, news, etc. etc.) is wiki driven which then links to release documentation directories which are generated from svn sources during a release. But either way is good. Good to know the site is coming soon! > Patrick > > Hiram Chirino wrote: >> >> Is the ZooKeeper website getting moved over to Apache? I think a good >> website is critical for building a community around the project. >> >> Do you guys want to generate it from wiki content? For example, the >> http://activemq.apache.org/ site is generated from the wiki content at >> http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index >> >> If so I think I can create the confluence space for you guys so that >> we can get started with that. >> >> >> >> > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
Re: Website
The Hadoop project, including ZooKeeper, is currently using the Apache wiki. There are no plans at this time to use confluence: http://wiki.apache.org/hadoop/ZooKeeper Patrick Hiram Chirino wrote: On Tue, Jul 22, 2008 at 2:54 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: I cloned core/hbase subprojects, so we do what's currently done by other hadoop subs. The issue has come up in the past, might be a good idea at some point but might also add even more complexity to already pretty complex process (see howtorelease page). I think we should get things setup similar to existing subs (still alot of work to be done converting the wiki over to apache wiki/docs) and review at some point in the future. Howtocontrib/howtorelease/faq is already on the wiki: http://wiki.apache.org/hadoop/ZooKeeper mailinglists/news/etc... are part of the docs (not wiki), probably more convention than anything. mailinglist never changes and I believe news (and prolly some others) is part of docs in order to be versioned, but also to enable users who have checked out the code to have direct access . That's cool too.. If you are going to use a Wiki it might be better to use the confluence one just cause it can easily be skinned to have the main site's look and feel. Plus it has a bunch of cool macros available to import code examples from svn or bring in a table of issues from JIRA (for example http://openejb.apache.org/ejb-3-roadmap.html ) etc. Regards, Hiram Patrick Hiram Chirino wrote: On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: Hi Hiram, see ZOOKEEPER-70 & 72. We'll be following Hadoop core/hbase wrt the docs/site/wiki. Specifically using Apache Forrest for the documentation, which also generates the site. We're in the process of moving the sourceforge wiki content over from SF to apache. I'm been working with a couple of the hadoop core team members getting their input re the site, I had actually planned to push something live today. Additional complexity is due to the fact that on SF we had all docs on the wiki and were not including the api docs in the release. Apache requires us to version our documentation proper along with the code (so has to be in SVN and not on the wiki) and we also have to include the api docs (as well as regular docs) along with each release which we are not doing on SF. Yep. BTW you can still take a hybrid approach where the general site information (stuff like how to contirbute, mailing lists, news, etc. etc.) is wiki driven which then links to release documentation directories which are generated from svn sources during a release. But either way is good. Good to know the site is coming soon! Patrick Hiram Chirino wrote: Is the ZooKeeper website getting moved over to Apache? I think a good website is critical for building a community around the project. Do you guys want to generate it from wiki content? For example, the http://activemq.apache.org/ site is generated from the wiki content at http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index If so I think I can create the confluence space for you guys so that we can get started with that.
Re: Website
On Tue, Jul 22, 2008 at 2:54 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > I cloned core/hbase subprojects, so we do what's currently done by other > hadoop subs. The issue has come up in the past, might be a good idea at some > point but might also add even more complexity to already pretty complex > process (see howtorelease page). I think we should get things setup similar > to existing subs (still alot of work to be done converting the wiki over to > apache wiki/docs) and review at some point in the future. > > Howtocontrib/howtorelease/faq is already on the wiki: > http://wiki.apache.org/hadoop/ZooKeeper > > mailinglists/news/etc... are part of the docs (not wiki), probably more > convention than anything. mailinglist never changes and I believe news (and > prolly some others) is part of docs in order to be versioned, but also to > enable users who have checked out the code to have direct access . > That's cool too.. If you are going to use a Wiki it might be better to use the confluence one just cause it can easily be skinned to have the main site's look and feel. Plus it has a bunch of cool macros available to import code examples from svn or bring in a table of issues from JIRA (for example http://openejb.apache.org/ejb-3-roadmap.html ) etc. Regards, Hiram > Patrick > > Hiram Chirino wrote: >> >> On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: >>> >>> Hi Hiram, see ZOOKEEPER-70 & 72. We'll be following Hadoop core/hbase wrt >>> the docs/site/wiki. Specifically using Apache Forrest for the >>> documentation, >>> which also generates the site. We're in the process of moving the >>> sourceforge wiki content over from SF to apache. >>> >>> I'm been working with a couple of the hadoop core team members getting >>> their >>> input re the site, I had actually planned to push something live today. >>> >>> Additional complexity is due to the fact that on SF we had all docs on >>> the >>> wiki and were not including the api docs in the release. Apache requires >>> us >>> to version our documentation proper along with the code (so has to be in >>> SVN >>> and not on the wiki) and we also have to include the api docs (as well as >>> regular docs) along with each release which we are not doing on SF. >> >> Yep. BTW you can still take a hybrid approach where the general site >> information (stuff like how to contirbute, mailing lists, news, etc. >> etc.) is wiki driven which then links to release documentation >> directories which are generated from svn sources during a release. >> But either way is good. Good to know the site is coming soon! >> >>> Patrick >>> >>> Hiram Chirino wrote: Is the ZooKeeper website getting moved over to Apache? I think a good website is critical for building a community around the project. Do you guys want to generate it from wiki content? For example, the http://activemq.apache.org/ site is generated from the wiki content at http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index If so I think I can create the confluence space for you guys so that we can get started with that. >> >> >> > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
Re: Website
I cloned core/hbase subprojects, so we do what's currently done by other hadoop subs. The issue has come up in the past, might be a good idea at some point but might also add even more complexity to already pretty complex process (see howtorelease page). I think we should get things setup similar to existing subs (still alot of work to be done converting the wiki over to apache wiki/docs) and review at some point in the future. Howtocontrib/howtorelease/faq is already on the wiki: http://wiki.apache.org/hadoop/ZooKeeper mailinglists/news/etc... are part of the docs (not wiki), probably more convention than anything. mailinglist never changes and I believe news (and prolly some others) is part of docs in order to be versioned, but also to enable users who have checked out the code to have direct access . Patrick Hiram Chirino wrote: On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: Hi Hiram, see ZOOKEEPER-70 & 72. We'll be following Hadoop core/hbase wrt the docs/site/wiki. Specifically using Apache Forrest for the documentation, which also generates the site. We're in the process of moving the sourceforge wiki content over from SF to apache. I'm been working with a couple of the hadoop core team members getting their input re the site, I had actually planned to push something live today. Additional complexity is due to the fact that on SF we had all docs on the wiki and were not including the api docs in the release. Apache requires us to version our documentation proper along with the code (so has to be in SVN and not on the wiki) and we also have to include the api docs (as well as regular docs) along with each release which we are not doing on SF. Yep. BTW you can still take a hybrid approach where the general site information (stuff like how to contirbute, mailing lists, news, etc. etc.) is wiki driven which then links to release documentation directories which are generated from svn sources during a release. But either way is good. Good to know the site is coming soon! Patrick Hiram Chirino wrote: Is the ZooKeeper website getting moved over to Apache? I think a good website is critical for building a community around the project. Do you guys want to generate it from wiki content? For example, the http://activemq.apache.org/ site is generated from the wiki content at http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index If so I think I can create the confluence space for you guys so that we can get started with that.
Re: Website
On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > Hi Hiram, see ZOOKEEPER-70 & 72. We'll be following Hadoop core/hbase wrt > the docs/site/wiki. Specifically using Apache Forrest for the documentation, > which also generates the site. We're in the process of moving the > sourceforge wiki content over from SF to apache. > > I'm been working with a couple of the hadoop core team members getting their > input re the site, I had actually planned to push something live today. > > Additional complexity is due to the fact that on SF we had all docs on the > wiki and were not including the api docs in the release. Apache requires us > to version our documentation proper along with the code (so has to be in SVN > and not on the wiki) and we also have to include the api docs (as well as > regular docs) along with each release which we are not doing on SF. Yep. BTW you can still take a hybrid approach where the general site information (stuff like how to contirbute, mailing lists, news, etc. etc.) is wiki driven which then links to release documentation directories which are generated from svn sources during a release. But either way is good. Good to know the site is coming soon! > > Patrick > > Hiram Chirino wrote: >> >> Is the ZooKeeper website getting moved over to Apache? I think a good >> website is critical for building a community around the project. >> >> Do you guys want to generate it from wiki content? For example, the >> http://activemq.apache.org/ site is generated from the wiki content at >> http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index >> >> If so I think I can create the confluence space for you guys so that >> we can get started with that. >> > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
Re: Website
Hi Hiram, see ZOOKEEPER-70 & 72. We'll be following Hadoop core/hbase wrt the docs/site/wiki. Specifically using Apache Forrest for the documentation, which also generates the site. We're in the process of moving the sourceforge wiki content over from SF to apache. I'm been working with a couple of the hadoop core team members getting their input re the site, I had actually planned to push something live today. Additional complexity is due to the fact that on SF we had all docs on the wiki and were not including the api docs in the release. Apache requires us to version our documentation proper along with the code (so has to be in SVN and not on the wiki) and we also have to include the api docs (as well as regular docs) along with each release which we are not doing on SF. Patrick Hiram Chirino wrote: Is the ZooKeeper website getting moved over to Apache? I think a good website is critical for building a community around the project. Do you guys want to generate it from wiki content? For example, the http://activemq.apache.org/ site is generated from the wiki content at http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index If so I think I can create the confluence space for you guys so that we can get started with that.
