Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of tjfrazier@cfl.rr.com
 designates 75.180.132.122 as permitted sender)
Message-ID: <4E810CA2.1060501@cfl.rr.com>
Date: Mon, 26 Sep 2011 19:37:06 -0400
From: TJ Frazier <tjfrazier@cfl.rr.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?
References: 
 <CAP-ksojAsNoJRFi+ay-QAP=x7-9wAHyPmRz5CJeMteYpgFVxsA@mail.gmail.com>
 <4E693D9C.7040809@cfl.rr.com>
 <CAP-ksohs+2Z41KoWnzhZ-N-Mw1+2RyVJgBSqY1s8z886g_Bc1Q@mail.gmail.com>
 <4E733EF1.9040805@cfl.rr.com>
 <CAP-ksojPND1mk38RegcgpvrUuSthcCEG1kVdZ3y73Rr_6vFZkg@mail.gmail.com>
 <CAGj321545+R6WFwM0B5oVNL-NRxFm46afBa0506QKeYZZiL0ZA@mail.gmail.com>
In-Reply-To: 
 <CAGj321545+R6WFwM0B5oVNL-NRxFm46afBa0506QKeYZZiL0ZA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi, Kay,
On 9/26/2011 18:28, Kay Schenk wrote:
> Hi. I just posted (really asked a question) on this same subject on another
> thread -- vis a vis what's going on with the wiki.
>
> So, what IS going on? Anybody?
>
> I think (thought?) Pedro was kind of coordinating the test of Confluence
> with the infra folks but ???
>
AFAIK, there is nothing going on with the wiki. My objections to Cwiki 
are posted below; briefly, conversion would be too big and too messy to 
cope with.

Moin-moin might be a better candidate. Like Confluence, moin-moin is 
supported by infra (good), and lacks some facilities of Mwiki (bad). 
However, it has two distinct advantages:
* It is FOSS. If we decide that we need to extend it, whether for 
conversion or for permanent enhancements, we can do that.
* It is Python-powered. Python expertise should be available. I think I 
could learn enough to be useful, very quickly, without becoming a 
potential single-point-of-failure personnel problem.

I'm not the kind of person who can drive a project. We need someone who 
is. --/tj/

> On Fri, Sep 16, 2011 at 5:27 AM, Rob Weir<robweir@apache.org>  wrote:
>
>> On Fri, Sep 16, 2011 at 8:20 AM, TJ Frazier<tjfrazier@cfl.rr.com>  wrote:
>>> On 9/15/2011 15:30, Rob Weir wrote:
>>>>
>>>> On Thu, Sep 8, 2011 at 6:11 PM, TJ Frazier<tjfrazier@cfl.rr.com>
>>   wrote:
>>>>>
>>>>> On 9/6/2011 18:12, Rob Weir wrote:
>>>
>>>>> <snip>
>>>>>>
>>>>>> Another option to consider is that of content translation: MediaWiki
>>>>>> to Confluence.  Remember. Confluence is fully supported by Apache
>>>>>> Infra.  We would also find a lot of people on the list who could help
>>>>>> write and test wiki text conversion code.  It is just string
>>>>>> manipulation, right?  How hard can that be?  Even I can help with
>>>>>> that.
>>>>>>
>>>>>> But seriously, the MW plans were always precarious.  We did not have a
>>>>>> deep bench of expertise on the sys admin side of that package.  Even
>>>>>> if we have a volunteer or two step in now, aren't we still rather
>>>>>> thin?  Wouldn't we still be one "life change" away from being back
>>>>>> where we are now?  But if we can figure out a content-level migration
>>>>>> to Confluence wiki, then we would have something much more sustainable
>>>>>> long term.
>>>>>>
>>>>>> Just an idea.
>>>>>>
>>>>>> -Rob
>>>>>>
>>>>> My question is, "Is it worth looking at Confluence Wiki /at all?/ "
>>>>>
>>>>> Q: Why does everybody use Cwiki?
>>>>> A: Infra supports it.
>>>>> Q: Why does Infra support Cwiki?
>>>>> A: Everybody uses it.
>>>>> Hmm. "Very interesting," as Arte Johnson used to say.
>>>>>
>>>>
>>>> This is true, but there is more here than may be immediately evident.
>>>>
>>>> The fact that a service is widely supported by Apache Infra is very
>>>> important.  Remember, we no longer have Oracle's full-time web admin
>>>> staff to mind the OOo severs.  We'll soon be independent of that and
>>>> Apache will be responsible for routine maintenance, upgrades as well
>>>> as responding to problems.
>>>>
>>>> And we must not underestimate the potential for problems.  Apache is a
>>>> high profile target. So is OpenOffice. Mix them together and the
>>>> question is not "if" someone will attack our website and try to take
>>>> it down.  The question is "when?".
>>>>
>>>> I don't say that to scare you.  Just to point out reality.
>>>
>>> But is it reality?
>>>
>>> Apache has no big lists of credit-card numbers, no treasure-trove of
>> secret
>>> diplomatic cables, no maps of nuclear weapons targets or locations. What
>> we
>>> do have is software source, and that's free for the asking. In short, we
>>> have nothing that's worth a "commercial" (money-seeking) cracker's time.
>>>
>>> AFAIK, the ASF takes no stand on political, religious, or other
>> ideological
>>> controversies. We should not draw fanatics, either.
>>>
>>> The one credible threat I see is the possibility of inserting malware
>> into
>>> an Apache distro. That should not be possible through the wiki � any
>> brand
>>> of wiki.
>>>
>>
>> If you look at recent attacks, the trend appears to be to exploit a
>> XSS vulnerability (or other0) to get root access, get the user account
>> data, typically user name, email address and hashed password, then do
>> an offline rainbow table attack on the hashed passwords, and use that
>> information to break into other accounts on other systems, since many
>> users use identical login/password on multiple systems.
>>
>> It isn't really about the content of the wiki per se.  It is the account
>> data.
>>
>>> (Not to mention that any target on our backs wouldn't even fill the
>> ten-ring
>>> of the target on Wikipedia � one of the most popular sites in the world.
>>> Their code may not be bullet-proof, but it's close.)
>>>>
>>>> It is worth looking back at the note from Mark Thomas [1] sent to the
>>>> list back in July, to understand what it means to be using an
>>>> unsupported server app at Apache:
>>>>
>>>> "The much more important question is who will support it. There have
>>>> been far too many examples of projects requesting a service, promising
>>>> to help support it and then never being heard from again when it needs
>>>> maintenance. If the current maintenance is performed by Oracle rather
>>>> than the community there will be concerns about the viability of that
>>>> model.
>>>>
>>>> On a related note, infrastructure will not tolerate project managed
>>>> systems that are insecure. We will shut them down first and ask
>>>> questions later. Projects are expected to keep on top of security for
>>>> the services that they manage. We do arrange things so projects can
>>>> only shoot themselves in the foot but will still expect security to be
>>>> maintained. "
>>>
>>> I *assume* that the issue here is the timely installation of
>>> security-related updates, a high-priority maintenance task. Such updates
>> for
>>> FOSS components do happen � witness the recent flap over digital
>>> certificates � but they are quite rare. With the exception of the
>> MediaWiki
>>> code itself, updating the other components should be a cookbook task for
>>> anyone with sufficient karma and fu to have root access. It is generally
>>> simple enough that even I would take a crack at it (working slowly and
>>> carefully, and reading the instructions *first*. And not taking any
>>> "obvious" short-cuts ;-) ).
>>>
>>> Updating the MW code is a problem, with extensions, local mods, and
>>> leading-edge policy to consider. While there is expertise in the
>> background,
>>> we have not identified any active contributor (apparently including
>> Infra)
>>> with the expertise to JFDI.
>>>>
>>>> I fully acknowledge that moving to CWiki would result in an imperfect
>>>> translation of the content that will take additional effort to clean
>>>> up.  And that moving to MWiki will be faster.  But we only need to
>>>> migrate once, right?  But we need to maintain this for the next 10
>>>> years.  That is why I talked about CWiki being "more sustainable".
>>>> Sure, it is pain now.  But we'll have much more help at Apache going
>>>> forward if we're using the same software that everyone else uses.  If
>>>> we use MWiki, we may migrate faster, but we'll be shut down at the
>>>> first sign of a problem.
>>>>
>>>> I'm not saying the MWiki is unworkable.  But if we really want this to
>>>> work, long term, then we should be looking to have a solid base of
>>>> admin experience to help maintain it in the long term.  Not just help
>>>> migrating, but longer term.  And not just one person, but maybe 3
>>>> people who know it well and another 2 who can start learning it now.
>>>> Remember, the OOo wiki was not just a little thing on the fringes of
>>>> the project.  It was at the center of how the project was run.  Having
>>>> a sustainable wiki is essential for the AOOo project.
>>>>
>>>> [1] http://markmail.org/message/b23uko3fro5ijqkz
>>>>
>>>>
>>>> -Rob
>>>>
>>> <snip>
>>> Long-term sustainability is definitely a problem. Fortunately, it is a
>>> long-term problem: we have time to find a solution. For instance, maybe
>>> someone(s) at MWF would be pleased to take an active role at ASF. (Or,
>> maybe
>>> not.) We could ask.
>>>
>>> Personally, I am only one of the "start learning" folks. I don't want to
>> be
>>> in a single-point-of-failure position; I am pushing 70, and 70 is pushing
>>> back.
>>>
>>> Should conversion ultimately be required, it is worth taking a look at
>>> moin-moin. That /is/ supported by Infra, and it is FOSS. If we really
>> need
>>> some feature, we can add it; python expertise should be widely available.
>>> --
>>> /tj/
>>>
>>>
>>
>
>
>