You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Hiram Chirino <hi...@hiramchirino.com> on 2008/07/22 15:56:01 UTC
Website
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
Posted by Patrick Hunt <ph...@apache.org>.
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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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
<ja...@gmail.com> wrote:
> 2008/7/23 Doug Cutting <cu...@apache.org>:
>> 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
Posted by Doug Cutting <cu...@apache.org>.
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
Posted by James Strachan <ja...@gmail.com>.
2008/7/23 Doug Cutting <cu...@apache.org>:
> 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
Posted by Doug Cutting <cu...@apache.org>.
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
Posted by Patrick Hunt <ph...@apache.org>.
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 <hi...@hiramchirino.com>:
>> 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
Posted by James Strachan <ja...@gmail.com>.
2008/7/22 Hiram Chirino <hi...@hiramchirino.com>:
> 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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <ph...@apache.org> 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 <ph...@apache.org> 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 <ph...@apache.org> 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
Posted by Patrick Hunt <ph...@apache.org>.
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 <ph...@apache.org> 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 <ph...@apache.org> 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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Tue, Jul 22, 2008 at 2:54 PM, Patrick Hunt <ph...@apache.org> 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 <ph...@apache.org> 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
Posted by Patrick Hunt <ph...@apache.org>.
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 <ph...@apache.org> 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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt <ph...@apache.org> 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
Posted by Patrick Hunt <ph...@apache.org>.
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.
>