On 9/15/2011 15:30, Rob Weir wrote:
On Thu, Sep 8, 2011 at 6:11 PM, TJ Frazier<[email protected]> 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.
(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/
