You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Ryan McKinley <ry...@gmail.com> on 2007/12/07 08:09:00 UTC
Confluence wiki vs MoinMoin
I think its safe to say we that the solr wiki is not nearly as complete
as it could/should be. I've added a ton of stuff to 1.3 that needs some
documentation. Beyond the normal, 'I dislike writing docs' thing, I
find writing things in MoinMoin disappointing and even less fun then it
needs to be. For all the work you put into it, it never really looks
good.
Compare:
http://wiki.apache.org/solr/MultiCore
To:
http://cwiki.apache.org/WICKET/dropdownchoice-examples.html
I know it is a bit severe to suggest switching wikis, but I'll throw it
out there and see how you all feel about it.
If we did decide to switch, importing should not be too hard:
http://confluence.atlassian.com/display/CONFEXT/MoinMoin+Importer
Another cool thing about the Confluence wiki is a plugin that takes wiki
snapshots for each release. I remember some concern with apache
licensing issues.... wicket does it, so maybe its ok
http://code.google.com/p/couldit-autoexport/
Another crazy suggestion from ryan?
Maybe I should sleep on it?
thoughts?
Re: Confluence wiki vs MoinMoin
Posted by Grant Ingersoll <gs...@apache.org>.
On Dec 7, 2007, at 2:09 AM, Ryan McKinley wrote:
> I think its safe to say we that the solr wiki is not nearly as
> complete as it could/should be. I've added a ton of stuff to 1.3
> that needs some documentation. Beyond the normal, 'I dislike
> writing docs' thing, I find writing things in MoinMoin disappointing
> and even less fun then it needs to be. For all the work you put
> into it, it never really looks good.
>
> Compare:
> http://wiki.apache.org/solr/MultiCore
> To:
> http://cwiki.apache.org/WICKET/dropdownchoice-examples.html
>
> I know it is a bit severe to suggest switching wikis, but I'll throw
> it out there and see how you all feel about it.
>
> If we did decide to switch, importing should not be too hard:
> http://confluence.atlassian.com/display/CONFEXT/MoinMoin+Importer
>
> Another cool thing about the Confluence wiki is a plugin that takes
> wiki snapshots for each release. I remember some concern with
> apache licensing issues.... wicket does it, so maybe its ok
> http://code.google.com/p/couldit-autoexport/
>
Just b/c Wicket is doing it, doesn't make it right. :-)
I've noticed the way Struts handles this, is they allow comments/
changes to be placed on to the Wiki, and then they are "committed" to
the Wiki by the committers. I don't recall if they require a
specific license grant like we do in JIRA. So, I am not sure if this
correct either. Might be worth asking on legal again.
-Grant
Re: Confluence wiki vs MoinMoin
Posted by Dennis Kubes <ku...@apache.org>.
If the solr community decides to go this way I would like to present the
same option to the nutch community.
Dennis Kubes
Ryan McKinley wrote:
> I think its safe to say we that the solr wiki is not nearly as complete
> as it could/should be. I've added a ton of stuff to 1.3 that needs some
> documentation. Beyond the normal, 'I dislike writing docs' thing, I
> find writing things in MoinMoin disappointing and even less fun then it
> needs to be. For all the work you put into it, it never really looks good.
>
> Compare:
> http://wiki.apache.org/solr/MultiCore
> To:
> http://cwiki.apache.org/WICKET/dropdownchoice-examples.html
>
> I know it is a bit severe to suggest switching wikis, but I'll throw it
> out there and see how you all feel about it.
>
> If we did decide to switch, importing should not be too hard:
> http://confluence.atlassian.com/display/CONFEXT/MoinMoin+Importer
>
> Another cool thing about the Confluence wiki is a plugin that takes wiki
> snapshots for each release. I remember some concern with apache
> licensing issues.... wicket does it, so maybe its ok
> http://code.google.com/p/couldit-autoexport/
>
> Another crazy suggestion from ryan?
> Maybe I should sleep on it?
> thoughts?
>
>
Re: Confluence wiki vs MoinMoin
Posted by Chris Hostetter <ho...@fucit.org>.
: Wow, I didn't even realize that individual user's could reset their personal
: theme. 'classic' is so much better!
:
: +1 on changing the default.
other people should try this out (just go to your UserPrefrences, change
the theme, and then force reload some pages) if enough people like
classic, then we can change the default.
changing the default appears to be self-servive for anyone in appsite,
(which is i think all Lucene PMC members?) ...
http://moinmoin.wikiwikiweb.de/HelpOnThemes
http://wiki.apache.org/general/HowToMakeWikiAdminRequests
-Hoss
Re: Confluence wiki vs MoinMoin
Posted by Mike Klaas <mi...@gmail.com>.
On 7-Dec-07, at 3:19 PM, Chris Hostetter wrote:
> Personally: I don't think MoinMoin is that bad of a wiki system ...
> then
> again, i have to deal with some extremely shitty wiki systems in
> the other
> aspects of my life, so maybe i just have low expectations. I'm all in
> favor of picking a better default theme if we want to start with
> that as a
> way to "freshen things up" ... i already customized all of my apache
> moinmoin accounts to use the "classic" theme because that default
> blue/grey one is so damn depressing.
Wow, I didn't even realize that individual user's could reset their
personal theme. 'classic' is so much better!
+1 on changing the default.
-Mike
Re: Confluence wiki vs MoinMoin
Posted by Ken Krugler <kk...@transpac.com>.
>: Looks like http://cwiki.apache.org/CWIKI/ answers all our
>licensing questions.
>: Notable:
>
>See also this previous discussion in Lucene-Java, notably this
>clarification from Doug...
>
>http://www.nabble.com/Created%3A-%28LUCENE-805%29-New-Lucene-Demo-tf3234570.html#a9242876
>
>If someone wants to investigate what it would take to switch to use
>Confluence for the main site and/or the wiki i say great ... but it's
>important to keep in mind that:
> a) we need to be able to include "official" docs in releases
> b) wiki pages editable by "anyone" can't be included in releases
>
>...which means either we need two seperete wikis, or an easy way to
>categorize pages as "official" vs "unofficial", let anyone edit/create
>unofficial pages, let only commiteres edit/create official pages, allow
>exporting of official pages. Depending on how it works, the interlinking
>of official/unofficial pages could get somewhat confusing if they were all
>powered by one system (having forrest vs moinmoin right now makes a really
>clear line that would start getting blurred otherwise)
FWIW, at Krugle we started off using MoinMoin and switched to
Confluence. In general it's been a good change for us, especially as
the scale and scope of our wiki activity increased. And the
integration with Jira can be very handy.
As far as different classes of pages, the easiest way to do that
would be to create spaces (I assume that's possible w/the Confluence
config that Apache would set up), where each space can have different
access rights based on groups of users.
I had a quickly hacked app that I used to convert some of our
MoinMoin pages from their markup syntax to Confluence. If the switch
to Confluence happens, I can look around for it.
-- Ken
--
Ken Krugler
Krugle, Inc.
+1 530-210-6378
"If you can't find it, you can't fix it"
Re: Confluence wiki vs MoinMoin
Posted by Chris Hostetter <ho...@fucit.org>.
: SOLRxSITE -- that will be hosted at:
Requested: https://issues.apache.org/jira/browse/INFRA-1441
-Hoss
Re: Confluence wiki vs MoinMoin
Posted by Ryan McKinley <ry...@gmail.com>.
Chris Hostetter wrote:
> : To get that going, it looks like a Project PMC needs to file a ticket with
> : infrastructure.
>
> I can do this (or ask Doug to do it if they really want it to be the
> chair) but just to clarify....
>
> : o Also specify the key name for the Space. The key name cannot be changed.
> : + If you use JIRA, you might want to use the same key name.
>
> ...do we want this to be "SOLR" or "SOLRxSITE" (which seems to be the
> convention if you are using CWIKI to power a project site)
>
> I think we want it to be "SOLRxSITE", with the expectation that after
> we've played with and assumeing we like it the "first" cwiki becomes the
> new "main site" available at http://lucene.apache.org/solr/ and then later
> we create a second cwiki named "SOLR" which anyone can edit (replacing the
> MoinMoin wiki) at the url http://cwiki.apache.org/SOLR
>
> correct?
>
SOLRxSITE -- that will be hosted at:
http://lucene.apache.org/solr/
we could put "official" docs under:
http://lucene.apache.org/solr/docs/ (or something like that)
Re: Confluence wiki vs MoinMoin
Posted by Chris Hostetter <ho...@fucit.org>.
: To get that going, it looks like a Project PMC needs to file a ticket with
: infrastructure.
I can do this (or ask Doug to do it if they really want it to be the
chair) but just to clarify....
: o Also specify the key name for the Space. The key name cannot be changed.
: + If you use JIRA, you might want to use the same key name.
...do we want this to be "SOLR" or "SOLRxSITE" (which seems to be the
convention if you are using CWIKI to power a project site)
I think we want it to be "SOLRxSITE", with the expectation that after
we've played with and assumeing we like it the "first" cwiki becomes the
new "main site" available at http://lucene.apache.org/solr/ and then later
we create a second cwiki named "SOLR" which anyone can edit (replacing the
MoinMoin wiki) at the url http://cwiki.apache.org/SOLR
correct?
-Hoss
Re: Confluence wiki vs MoinMoin
Posted by Ryan McKinley <ry...@gmail.com>.
Yonik Seeley wrote:
> On Dec 11, 2007 9:29 AM, Ryan McKinley <ry...@gmail.com> wrote:
>> Do we feel ok about moving forward with step #0? That is request a
>> cwiki site and evaluate it.
>
> +1
>
To get that going, it looks like a Project PMC needs to file a ticket
with infrastructure.
From the wiki:
How do we request a CWIKI Space?
* New Spaces can be created upon request of a ASF Project PMC
* File a ticket for the Confluence component.
o Include the cwiki account name of a PMC member (preferably the PMC
chair) who will help administer the space.
o Also specify the key name for the Space. The key name cannot be
changed.
+ If you use JIRA, you might want to use the same key name.
* When the Space is created, a $project-committer group (or equivalent)
will also be created with full rights to the Project's Space.
ryan
Re: Confluence wiki vs MoinMoin
Posted by Yonik Seeley <yo...@apache.org>.
On Dec 11, 2007 9:29 AM, Ryan McKinley <ry...@gmail.com> wrote:
> Do we feel ok about moving forward with step #0? That is request a
> cwiki site and evaluate it.
+1
-Yonik
Re: Confluence wiki vs MoinMoin
Posted by Ryan McKinley <ry...@gmail.com>.
Chris Hostetter wrote:
> : Javadocs aren't appropriate for documenting configuration and RequestHandler
> : parameters/usage. These are used by many non-java folks and should have
> : nothing to do with the java class structure/methods/etc
>
> i agree that the generated javadocs are not very freindly for end users,
> but i think there is a lot of value in this kind of documentation living
> in the code so it can be kept uptodate as the code is changed (hence my
> suggestion about maybe having a custom doclet for generating a more user
> freindly output of just the freeform "class" javadocs (without the methods
> and package structure information)
>
As long as we have a consistent answer for where param/behavior docs go,
I'm happy with (almost) any convention. Perhaps all 'end-user' docs
would go under:
http://lucene.apache.org/solr/api/org/apache/solr/common/params/package-summary.html
In my view the best approach may be:
'end-user' docs (params+behavior/use cases/configuration) goes in cwiki
'plugin' overview in cwiki
'plugin' details in javadocs
Implementation details in javadocs. Javadocs should link to the
relevant cwiki page for usage.
>
> : My thought is that nothing new would go there. Hopefully we could make the
> : "sandbox" a section of cwiki with no user permissions that does not get
> : included in the docs.
>
> that's great ... but it stil leaves the MoinMoin wiki getting old,
> stagnent, looking different from everything else, and requiring a
> differnet syntax to be edited (like when we want to note that a param has
> been deprecated in later versions of Solr or something) ... it becomes an
> "image problem" to leave it up and running for very long.
>
In my plan, the MoinMoin wiki would be accurate for release 1.2 -- it
should stay around as long as 1.2 is a useful release. This would not
get updated docs even if they are 1.2 relevant. (unless someone REALLY
wants to update them)
As long as the pages are well marked with a warning that new stuff is on
a different site and contains a link to that site I think the image is ok.
ryan
Re: Confluence wiki vs MoinMoin
Posted by Chris Hostetter <ho...@fucit.org>.
: Javadocs aren't appropriate for documenting configuration and RequestHandler
: parameters/usage. These are used by many non-java folks and should have
: nothing to do with the java class structure/methods/etc
i agree that the generated javadocs are not very freindly for end users,
but i think there is a lot of value in this kind of documentation living
in the code so it can be kept uptodate as the code is changed (hence my
suggestion about maybe having a custom doclet for generating a more user
freindly output of just the freeform "class" javadocs (without the methods
and package structure information)
: I'm not sure #2 is a big deal. The cwiki info site specifically says
: "Incidental comments about a page would not require that a CLA to be on file"
Ah ... good call.
: > : 2. We keep http://wiki.apache.org/solr/ as an unofficial sandbox and pre
: > i'm assuming we might eventually want to migrate this to a seperate cwiki
: > space just for our own sanity (single syntax, single look/feel, etc...) but
: > i agree this doesn't need to happen any time soon.
: My thought is that nothing new would go there. Hopefully we could make the
: "sandbox" a section of cwiki with no user permissions that does not get
: included in the docs.
that's great ... but it stil leaves the MoinMoin wiki getting old,
stagnent, looking different from everything else, and requiring a
differnet syntax to be edited (like when we want to note that a param has
been deprecated in later versions of Solr or something) ... it becomes an
"image problem" to leave it up and running for very long.
-Hoss
Re: Confluence wiki vs MoinMoin
Posted by Ryan McKinley <ry...@gmail.com>.
>
> even if we switch to cwiki, I still think javadocs are the best way to go
> for "official" plugin docs because of hte code/doc proximity advantages
> ... but if they aren't user friendly enough for typical users then maybe
> we could look into hacking together a custom doclet to just output the
> class level docs and not hte method details?
For plugin/embedded docs, I agree javadocs are the correct place.
Plugin authors need to be java savvy and will be working with the java
interfaces, so there is no need for special doclet.
Javadocs aren't appropriate for documenting configuration and
RequestHandler parameters/usage. These are used by many non-java folks
and should have nothing to do with the java class structure/methods/etc
>
> : Having read all the rules, this is my proposal:
>
> +1 to the bulk of your proposal, but a few comments...
>
> I would like to suggest a step #0: There doesn't seem to be a cwiki
> sandbox we can use to test stuff out, so after getting a solr cwiki
> created, let's do some experiments with the exporting and make sure we can
> viably export docs that:
> 1) use all relative links (like forrest)
> 2) don't contain "user comments" from non cla users
> ..so we can be confident the exports can be included as documentation with
> releases before we spend a lot of time building up the new docset.
I'm not sure #2 is a big deal. The cwiki info site specifically says
"Incidental comments about a page would not require that a CLA to be on
file" Assuming we all get notified of all changes, inappropriate
comments would be deleted and substantial ones likely integrated into
the main page. "Incidental" ones could remain as is.
But yes, I agree we should set it up and play with it before committing
to it.
>
> : 2. We keep http://wiki.apache.org/solr/ as an unofficial sandbox and pre 1.3
> : docs. Anyone can edit it, but it is not official.
>
> i'm assuming we might eventually want to migrate this to a seperate
> cwiki space just for our own sanity (single syntax, single look/feel,
> etc...) but i agree this doesn't need to happen any time soon.
>
My thought is that nothing new would go there. Hopefully we could make
the "sandbox" a section of cwiki with no user permissions that does not
get included in the docs.
> : For now, i think we should stick with forrest for the website and tutorial.
> : When the tutorial gets revisited, http://cwiki.apache.org/SOLRxSITE/ may be a
>
> i think the current site (including the tutorial) would probably make the
> best "initial" docs to put into the new cwiki to test it out since we
> *know* the legal issues with them are okay and we know they should be
> included in all releases. eliminating forrest from the equation
> early on would also help simplify the "documentation dilution" issues of
> having forrest docs, wiki docs, and cwiki docs all at once -- especially
> if in Solr 1.3 (or 1.4 ... whenever it happens) the release itself
> includes overview docs and a tutorial generated by forrest with other docs
> generated from a cwiki dump ... the odds of getting those to all hyperlink
> with eachother cleanly seems very low.
>
yup.
Do we feel ok about moving forward with step #0? That is request a
cwiki site and evaluate it.
ryan
Re: Confluence wiki vs MoinMoin
Posted by Chris Hostetter <ho...@fucit.org>.
: What is really missing is that we don't (at least I don't) have a clear sense
: where what type of docs should go. Some in javadocs, some on the wiki, almost
: none on the forrest site. Javadocs work great since they are attached to
: sources and get included in releases. But solr's users are not all javadoc
: readers (nor should they be). Solr docs really should be in a non java
: specific context.
Once upon a time the plan (or at least my plan) was that how/what/why
documentation for provided plugins (dismax, fieldtypes, analysis
factories, etc...) would live (close to the code) in class level javadocs
-- our users may not be javadoc readers, but we could link straight to the
good pits from user centric forrest based "overview" pages. The
wiki would be a way for users to write "tips and tricks" type docs.
But things didn't really work out that way ... as simple as forrest is to
use to generate pages, it's not the most freindly tool to add and
organicly grow a set of documentation ... plus we made the decision early
on to start a lot of docs on the wiki "to flesh them out and make them
easier to tweak" with the intention of eventually migrating them to
"official" forrest docs .... except that we didn't know then what we know
now about the legal issues -- but even before we knew about the legal
issues, no one ever really had the inclination to migrate any of the docs.
even if we switch to cwiki, I still think javadocs are the best way to go
for "official" plugin docs because of hte code/doc proximity advantages
... but if they aren't user friendly enough for typical users then maybe
we could look into hacking together a custom doclet to just output the
class level docs and not hte method details?
: Having read all the rules, this is my proposal:
+1 to the bulk of your proposal, but a few comments...
I would like to suggest a step #0: There doesn't seem to be a cwiki
sandbox we can use to test stuff out, so after getting a solr cwiki
created, let's do some experiments with the exporting and make sure we can
viably export docs that:
1) use all relative links (like forrest)
2) don't contain "user comments" from non cla users
..so we can be confident the exports can be included as documentation with
releases before we spend a lot of time building up the new docset.
: 2. We keep http://wiki.apache.org/solr/ as an unofficial sandbox and pre 1.3
: docs. Anyone can edit it, but it is not official.
i'm assuming we might eventually want to migrate this to a seperate
cwiki space just for our own sanity (single syntax, single look/feel,
etc...) but i agree this doesn't need to happen any time soon.
: For now, i think we should stick with forrest for the website and tutorial.
: When the tutorial gets revisited, http://cwiki.apache.org/SOLRxSITE/ may be a
i think the current site (including the tutorial) would probably make the
best "initial" docs to put into the new cwiki to test it out since we
*know* the legal issues with them are okay and we know they should be
included in all releases. eliminating forrest from the equation
early on would also help simplify the "documentation dilution" issues of
having forrest docs, wiki docs, and cwiki docs all at once -- especially
if in Solr 1.3 (or 1.4 ... whenever it happens) the release itself
includes overview docs and a tutorial generated by forrest with other docs
generated from a cwiki dump ... the odds of getting those to all hyperlink
with eachother cleanly seems very low.
-Hoss
Re: Confluence wiki vs MoinMoin
Posted by Ryan McKinley <ry...@gmail.com>.
> If someone wants to investigate what it would take to switch to use
> Confluence for the main site and/or the wiki i say great ... but it's
> important to keep in mind that:
> a) we need to be able to include "official" docs in releases
> b) wiki pages editable by "anyone" can't be included in releases
>
What is really missing is that we don't (at least I don't) have a clear
sense where what type of docs should go. Some in javadocs, some on the
wiki, almost none on the forrest site. Javadocs work great since they
are attached to sources and get included in releases. But solr's users
are not all javadoc readers (nor should they be). Solr docs really
should be in a non java specific context.
Right now, where should we put the dismax parameter docs? Currently we
have it on the wiki and in the javadocs (still in DisMaxRequestHandler
even though the functionality is in DisMaxQueryParser... but maybe the
docs should go on the DisMaxParms!)
I agree changing the MoinMoin theme makes it look a lot better but it
still does not address your point a) -- If we stick with the status quo,
we don't have official docs. We also don't have any way to have clean
docs relevant to a release. Deprecated things never go away, they just
stack up.
Having read all the rules, this is my proposal:
1. We set up an "official" documentation site and use the policy that
http://cwiki.apache.org/CWIKI/ suggests under "But what if we would like
the community at large to help maintain the space?"
Anyone who has a CLA on file will be able to edit the wiki. It is not
hard to do a CLA and I am confident many in the solr community will take
the time to do it. It actually seems like a good thing to get people
into the club. They send away for a magic decoder ring.
People without a CLA can post comments on a page. Either this stays as
a comment, or someone could incorporate it into the page.
2. We keep http://wiki.apache.org/solr/ as an unofficial sandbox and pre
1.3 docs. Anyone can edit it, but it is not official.
3. For licensing issues, we can't do a bulk import. Nor do I think we
want to. For each page, someone with CLA needs to:
1. Make sure the content complies with ASF copyright issues
2. copy 1.3 relevant data to cwiki
3. leave 1.2 data on wiki and add link to new page
We don't have to do it all at once, and it does not need to be done by
commiters. We don't have so much that it is too daunting to think we
could get through it before 1.3 release.
4. with release 1.3, we can include a snapshot of the cwiki for official
docs. After the release, additions to the that reference trunk would
get flagged with something like <!>["1.4-dev"] that would get removed
prior to the next release snapshot.
For now, i think we should stick with forrest for the website and
tutorial. When the tutorial gets revisited,
http://cwiki.apache.org/SOLRxSITE/ may be a good option.
sound reasonable?
ryan
Re: Confluence wiki vs MoinMoin
Posted by Chris Hostetter <ho...@fucit.org>.
: Looks like http://cwiki.apache.org/CWIKI/ answers all our licensing questions.
: Notable:
See also this previous discussion in Lucene-Java, notably this
clarification from Doug...
http://www.nabble.com/Created%3A-%28LUCENE-805%29-New-Lucene-Demo-tf3234570.html#a9242876
If someone wants to investigate what it would take to switch to use
Confluence for the main site and/or the wiki i say great ... but it's
important to keep in mind that:
a) we need to be able to include "official" docs in releases
b) wiki pages editable by "anyone" can't be included in releases
...which means either we need two seperete wikis, or an easy way to
categorize pages as "official" vs "unofficial", let anyone edit/create
unofficial pages, let only commiteres edit/create official pages, allow
exporting of official pages. Depending on how it works, the interlinking
of official/unofficial pages could get somewhat confusing if they were all
powered by one system (having forrest vs moinmoin right now makes a really
clear line that would start getting blurred otherwise)
Personally: I don't think MoinMoin is that bad of a wiki system ... then
again, i have to deal with some extremely shitty wiki systems in the other
aspects of my life, so maybe i just have low expectations. I'm all in
favor of picking a better default theme if we want to start with that as a
way to "freshen things up" ... i already customized all of my apache
moinmoin accounts to use the "classic" theme because that default
blue/grey one is so damn depressing.
-Hoss
Re: Confluence wiki vs MoinMoin
Posted by Ryan McKinley <ry...@gmail.com>.
Mike Klaas wrote:
> Both the wiki and the homepages look much nicer than the lucene/solr
> ones. More professional too, FWIW.
>
> Obviously the main issue here is manpower to convert everything. An
> easier solution might be to install a MoinMoin theme. see
> http://moinmoin.wikiwikiweb.de/ThemeMarket for many bad and some good
> examples (Balanced, used by ubuntu, seems reasonable).
>
Balanced looks good -- that could be a quick/easy option.
If folks are not opposed to the idea of changing wikis. I could try
running our existing docs through the "Universal Wiki Converter"
http://confluence.atlassian.com/display/CONFEXT/Universal+Wiki+Converter
to see what happens.
It looks like the wiki pages are stored on people.apache.org:
/x1/www/wiki.apache.org/data/solr/data/pages/
but with a few exceptions, I don't have permission to see the files:
[ryan@minotaur /x1/www/wiki.apache.org/data/solr/data/pages]$ ls -al
total 316
drwxr-xr-x 156 apmail apbackup 4608 Dec 7 04:19 .
drwxr-xr-x 6 apmail apbackup 512 Feb 14 2006 ..
drwxr-x--- 2 apmail apbackup 512 Feb 20 2007 AdminGroup
drwxr-x--- 3 apmail apbackup 512 Nov 18 20:19
AnalyzersTokenizersTokenFilters
drwxr-xr-x 3 apmail apbackup 512 Nov 27 17:55 BadContent
drwxr-x--- 3 apmail apbackup 512 Sep 10 15:37 Carolina(2b)Coast(2b)
drwxr-x--- 3 apmail apbackup 512 Sep 6 00:54
CategoryQueryResponseWriter
drwxr-x--- 3 apmail apbackup 512 Sep 18 00:10
CategorySolrRequestHandler
Does anyone have read access for that? Or know how to see them?
----
Looks like http://cwiki.apache.org/CWIKI/ answers all our licensing
questions. Notable:
>
> Can we use the autoexport site as part of our main web site?
>
> Only if everyone working on the autoexport site has a Contributors
> License Agreement on file.
>
They note that you don't have to be a "commiter", just have a CLA on file.
ryan
Re: Confluence wiki vs MoinMoin
Posted by Mike Klaas <mi...@gmail.com>.
Both the wiki and the homepages look much nicer than the lucene/solr
ones. More professional too, FWIW.
Obviously the main issue here is manpower to convert everything. An
easier solution might be to install a MoinMoin theme. see http://
moinmoin.wikiwikiweb.de/ThemeMarket for many bad and some good
examples (Balanced, used by ubuntu, seems reasonable).
-Mike
On 7-Dec-07, at 6:25 AM, Yonik Seeley wrote:
> One can apparently even use it for project home pages
>
> http://cwiki.apache.org/GMOxSITE/ http://geronimo.apache.org/
> http://cwiki.apache.org/MINA/ http://mina.apache.org/
> http://cwiki.apache.org/FELIX/ http://felix.apache.org
> http://cwiki.apache.org/ACTIVEMQ/ http://activemq.apache.org/
> http://cwiki.apache.org/TUSCANY/
> http://cwiki.apache.org/SLING/
>
> and other examples at http://cwiki.apache.org/
>
> -Yonik
>
> On Dec 7, 2007 2:09 AM, Ryan McKinley <ry...@gmail.com> wrote:
>> I think its safe to say we that the solr wiki is not nearly as
>> complete
>> as it could/should be. I've added a ton of stuff to 1.3 that
>> needs some
>> documentation. Beyond the normal, 'I dislike writing docs' thing, I
>> find writing things in MoinMoin disappointing and even less fun
>> then it
>> needs to be. For all the work you put into it, it never really looks
>> good.
>>
>> Compare:
>> http://wiki.apache.org/solr/MultiCore
>> To:
>> http://cwiki.apache.org/WICKET/dropdownchoice-examples.html
>>
>> I know it is a bit severe to suggest switching wikis, but I'll
>> throw it
>> out there and see how you all feel about it.
>>
>> If we did decide to switch, importing should not be too hard:
>> http://confluence.atlassian.com/display/CONFEXT/MoinMoin+Importer
>>
>> Another cool thing about the Confluence wiki is a plugin that
>> takes wiki
>> snapshots for each release. I remember some concern with apache
>> licensing issues.... wicket does it, so maybe its ok
>> http://code.google.com/p/couldit-autoexport/
>>
>> Another crazy suggestion from ryan?
>> Maybe I should sleep on it?
>> thoughts?
>>
>>
>>
Re: Confluence wiki vs MoinMoin
Posted by Yonik Seeley <yo...@apache.org>.
One can apparently even use it for project home pages
http://cwiki.apache.org/GMOxSITE/ http://geronimo.apache.org/
http://cwiki.apache.org/MINA/ http://mina.apache.org/
http://cwiki.apache.org/FELIX/ http://felix.apache.org
http://cwiki.apache.org/ACTIVEMQ/ http://activemq.apache.org/
http://cwiki.apache.org/TUSCANY/
http://cwiki.apache.org/SLING/
and other examples at http://cwiki.apache.org/
-Yonik
On Dec 7, 2007 2:09 AM, Ryan McKinley <ry...@gmail.com> wrote:
> I think its safe to say we that the solr wiki is not nearly as complete
> as it could/should be. I've added a ton of stuff to 1.3 that needs some
> documentation. Beyond the normal, 'I dislike writing docs' thing, I
> find writing things in MoinMoin disappointing and even less fun then it
> needs to be. For all the work you put into it, it never really looks
> good.
>
> Compare:
> http://wiki.apache.org/solr/MultiCore
> To:
> http://cwiki.apache.org/WICKET/dropdownchoice-examples.html
>
> I know it is a bit severe to suggest switching wikis, but I'll throw it
> out there and see how you all feel about it.
>
> If we did decide to switch, importing should not be too hard:
> http://confluence.atlassian.com/display/CONFEXT/MoinMoin+Importer
>
> Another cool thing about the Confluence wiki is a plugin that takes wiki
> snapshots for each release. I remember some concern with apache
> licensing issues.... wicket does it, so maybe its ok
> http://code.google.com/p/couldit-autoexport/
>
> Another crazy suggestion from ryan?
> Maybe I should sleep on it?
> thoughts?
>
>
>
Re: Confluence wiki vs MoinMoin
Posted by Henrib <hb...@gmail.com>.
I second that; it's always difficult to maintain documentation but having a
good looking end result always seem to reduce the amount of effort... Plus,
using Confluence, there are certainly a few things that could be nicely
linked to Jira (both being Atlassian products with a nice license for Open
Source projects).
I guess a 'prototype/proof-of-concept' conversion would need to be made
first; count me in if I can help.
ryantxu wrote:
>
> I think its safe to say we that the solr wiki is not nearly as complete
> as it could/should be. I've added a ton of stuff to 1.3 that needs some
> documentation. Beyond the normal, 'I dislike writing docs' thing, I
> find writing things in MoinMoin disappointing and even less fun then it
> needs to be. For all the work you put into it, it never really looks
> good.
>
> Compare:
> http://wiki.apache.org/solr/MultiCore
> To:
> http://cwiki.apache.org/WICKET/dropdownchoice-examples.html
>
> I know it is a bit severe to suggest switching wikis, but I'll throw it
> out there and see how you all feel about it.
>
> If we did decide to switch, importing should not be too hard:
> http://confluence.atlassian.com/display/CONFEXT/MoinMoin+Importer
>
> Another cool thing about the Confluence wiki is a plugin that takes wiki
> snapshots for each release. I remember some concern with apache
> licensing issues.... wicket does it, so maybe its ok
> http://code.google.com/p/couldit-autoexport/
>
> Another crazy suggestion from ryan?
> Maybe I should sleep on it?
> thoughts?
>
>
>
>
--
View this message in context: http://www.nabble.com/Confluence-wiki-vs-MoinMoin-tf4960631.html#a14211188
Sent from the Solr - Dev mailing list archive at Nabble.com.