The wiki of our roundup-development is currently hosted on Sourceforge
(for a number of years).

To confirm registrations, for notifications to reset password,
an outgoing email service is nice.

However Sourceforge stopped outgoing email service according to
 https://sourceforge.net/p/forge/site-support/15404/
the official support said that they had to stop all outside communication
of scripts because of abuse and their perceived legal obligation to
prevent it.
This is understandable. Thanks to Sourceforge for offering such a nice
service
for many years!

The problem be seen current if a password reset is attempted, 
it fails with "Connection to mailserver 'prwebmail' failed: [Errno 113]
No route to host"

So we have to look for alternatives.
Ideas:


a) We activate SF's own wiki service
  https://sourceforge.net/p/forge/documentation/Wiki/

  For this we would have to transform the old contents into the
different format,
  they use Markdown.
  Advantages: No extra credentials necessary, already integrated with
SF. HTTPS access.
  We do not have to maintain the wiki software itself.

b) We search for a different MoinMo.in provider
  Advantage: We are the customers as we will be paying (a low amount),
transforming
  contents is easy, we profit from an independent fully blown wiki
component and also
  promote it. HTTPS and email included.

c) We search for a hoster that offers us to run something.
  Advantage: We have full control. And the advantages of a full blown
competitive wiki engine.


We could ask the PSF that already runs our tracker hosting or Intevation
(my company),
which would fall between the b) and c) as Intevation runs a lot of
Moinmo.in wikis.

Give your feedback into the issue! (Thanks!)

Here is a list of Hoster for MoinMo.in instances
  https://moinmo.in/MoinMoinHosting
some entries seem to be outdated, there are only two hosters offering
a pre-installed MoinMoin and pricing starts at 180 USD/year.

Other lists of wiki hosters can be found here:
* https://en.wikipedia.org/wiki/Comparison_of_wiki_hosting_services
* https://www.mediawiki.org/wiki/Hosting_services

Given that our wiki requirements for roundup are low and
most of us want to spend less time administrating the wiki and more
into roundup development, my tendency right now is to move to SF's service.
SF runs Allura, which is a Free Software product, we maybe able to
become more of a customer if we volunteeringly pay.

Hi Bern:

In message <1551947118.97.0.680049436588.issue2551027@roundup.psfhosted.org>,
Bernhard Reiter writes:
>So we have to look for alternatives.
>Ideas:
>a) We activate SF's own wiki service
>  https://sourceforge.net/p/forge/documentation/Wiki/
>
>  For this we would have to transform the old contents into the
>  different format, they use Markdown.
>  Advantages: No extra credentials necessary, already integrated
>    with SF. HTTPS access.
>  We do not have to maintain the wiki software itself.
>
>b) We search for a different MoinMo.in provider
>  Advantage: We are the customers as we will be paying (a low amount),
>    transforming contents is easy, we profit from an independent
>    fully blown wiki component and also promote it. HTTPS and email included.
>
>c) We search for a hoster that offers us to run something.
>  Advantage: We have full control. And the advantages of a full blown
>    competitive wiki engine.

I have a few concerns:

 1) No loss/corruption of content. We have a lot of content that,
    because it includes python code, is brittle to
    transfer. Whitespace gets mangled easily and that causes semantic
    changes and bugs in python code. I have spent quite a few hours
    fixing pages in the wiki where whitespace rot has occurred.
 2) Anti-Spam controls. This was a problem in the past and is a
    concern for the future. Having a way to scrub spam if it occurs is
    going to be important. A way to control access (require magic key,
    or authorize users) to the wiki is a needed control if we wbend up
    in spam city.
 3) Vendor lock-in. The only thing I want to get locked into is
    roundup 8-).
 4) Support for HTTPS, RSS, and file/image attachments.
 4a) Being able to embed an attachment in the wiki page with syntax
    highlighting would be a nice to have. This would allow python code
    to be attached and the user can downloaded the file (preserving
    whitespace) rather than cut/paste.

It looks like the sourceforge wiki handles #4 but not #4a. I hope
because it ties into sourceforge, #2 is not an issue. #3 is an issue.
But if it reduces maintenance and we have some way to export the
content I am ok with it.

#1 is going to be the tricky issue. That argues for option b if
somebody is willing to pay for it.

Hi John,
thanks for your thoughts, which turn out to be more detailed requirements
we should weight in. I agree with all of them.

Yesterday I took an initial look about option a) (moving to SF) and
found out
the following:

i) we have 14MByte in the `data` directory, there seem to be many pages
   that got deleted as spam. And also there is a lot of history.

-> We should backup and clean out contents before we start "moving" in
all cases.
-> How many history do we want to preserve?

== History
Overall I like keeping history, with SCMs I think it is important, though
with our wiki I think it is an open question.

Option a) would not preserve history, which can be fine, if this is what
we want.
This holds for any other migration as well.

== Exploring Option b) and c)
Intevation maybe willing to contribute financially for a hoster. 
I'll ask Thomas Waldmann if there is a different option than the
business option
 his company is offering, which I think maybe unsuitable for a Free
Software initiative.

Maybe should approach the PSF and ask if this is something where they
would be willing
to help or rather not.

== a) needs conversion to a different markup

Documented I've found two possible ways to explore first:
1. Use moin2rst Formatter https://moinmo.in/FormatterMarket
   and additional scripting to get to rSt and
   then pandoc to convert to something else.

2. Use a html export and then pandoc.

It maybe an advantage if we could convert to a widely used Wikimarkup
like markdown variants. Regarding independence.

Both would require additional scripting.

Thomas Waldmann offers free wikis for Free Software, see
https://wikiwikiweb.de/FreeWiki

@ThomasAH, thanks for the hint.
In a narrow sense we do not meet the conditions for
https://wikiwikiweb.de/FreeWiki and I would want us to be customers.
I've written to  www.waldmann-edv.de to ask if there is a special offer
which is diffrent
from
https://order.shareit.com/product?vendorid=200089151&productid=300307419

== Option a) move to SF wiki
=== Code highlighting, inclusion

It seems that code highlighting works with SF's version of markdown:
 https://sourceforge.net/p/forge/documentation/markdown_syntax/#md_ex_code

Also it is possible to include files in a page, so the only question
would be if they would also be syntax highlighted.

== Option a) move to SF wiki
=== Code highlighting, inclusion
Inclusion of files with highlighting seems to work, see example at

https://sourceforge.net/p/roundup/wiki/SandBox/

Hi Bern:

In message <1552039613.38.0.724418710885.issue2551027@roundup.psfhosted.org>,
Bernhard Reiter writes:
>== Option a) move to SF wiki
>=== Code highlighting, inclusion
>Inclusion of files with highlighting seems to work, see example at
>
>https://sourceforge.net/p/roundup/wiki/SandBox/

That's an example of including a file from the repo. I meant including
an attached file inline in the wiki article. That doesn't seem to be
possible. There is an example of including an attached image, but I
didn't find any mention of including an attached (python) file inline.

== Option a) move to SF wiki
A drawback is that there are tags, but no hierachy of pages on SF.

A plus is, that the javascript editor is quite nice.

=== Code highlighting, inclusion
Added a feature request to SF
https://sourceforge.net/p/forge/feature-requests/692/

Hello!

After an explanation what we need, the small company
www.waldmann-edv.de from Moinmoin's maintainer Thomas Waldmann
makes us an offer to host an instance for 15 €/month payable in
a yearly installment.

To be checked:
* Does our custom style run on verison 1.9 (we are still using 1.8)
* Do we have any plugins or other customizations in use? (I guess we don't)

If we need one time (a project) support to migrate or for anything special,
we can get an offer by www.waldmann-edv.de, which will be a maximum of
90 €/h.
(All prices are stated with out potential VAT.)

In my personal observation 180 €/year will be saved
just on time to keep Moinmoin updated because of the experience of
Thomas Waldman. It is my understanding that we could move off this
hosting any time (and not renew payment for the next year). 

What do you think about the offer?

Note that my company Intevation would be willing bear the costs for this or
another solution for a foreseeable time. (Probably as long as we use
roundup intensively). A costs of 180 €/h year would probably be bearable
by others if Intevation would stop financing this.

On Tue, Mar 19, 2019 at 12:12:38PM +0000, Bernhard Reiter wrote:
...
> makes us an offer to host an instance for 15 €/month payable in
> a yearly installment.

As far as I understand, SF has native support for markdown (which
doesn't lock us into something), so I'd go with the standard free
offering. Unless the effort to convert to SF format is really huge.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com

Hi Ralf,

according to our evaluation so far, the SF wiki does **not meet**
the following features which are used by us right now:

* inline display of attached files (so that code examples can be
contributed)
* subpages, to be able to build a tree of wiki pages

So we are considering our options.
A markup conversion would be a medium chunk of work from my current
understanding.

If time is saved updating a wiki installation by us, it would mean more
time for roundup development.

Hi Bern:

In message <1553066228.0.0.459229370472.issue2551027@roundup.psfhosted.org>,
Bernhard Reiter writes:
>Bernhard Reiter added the comment:
>according to our evaluation so far, the SF wiki does **not meet**
>the following features which are used by us right now:
>
>* inline display of attached files (so that code examples can be contributed)

I raised the use case of embedding of attached files of source code.
I just checked: https://moinmo.in/HelpOnLinking and it doesn't look
like moinmoin handles that. They have documentation on embedding
images, but not source files.

I must have been thinking of some other wiki platform.

So I don't think this is an issue with the SF tracker.

>* subpages, to be able to build a tree of wiki pages

This would be useful.

>So we are considering our options.
>A markup conversion would be a medium chunk of work from my current
>understanding.

This is of more concern especially preserving whitespace in examples.

>If time is saved updating a wiki installation by us, it would mean more
>time for roundup development.

This is also a benefit from being able to move to another moinmoin platform.

Sorry for the embedding confusion. I could have sworn I had used the feature.

Ralf, John, 
so what do you think about the Waldmann-EDV offer overall?


== Preserving contributed code files
Another detail: It is probably easier to extend Moinmoin to display
attached files as code nicely, (maybe even with syntax highlighting)
than doing this will Allura's SF wiki engine. Moinmoin can be extended
by plugins and the options specialised-Moinmoin-Hosting or using a hoster
would allow us to run MoinMoin plugins.

Hi Bern:

In message <1553527603.69.0.0681748890547.issue2551027@roundup.psfhosted.org>,
Bernhard Reiter writes:
>Ralf, John, 
>so what do you think about the Waldmann-EDV offer overall?

I am ok with it. I think it would be an easier lift than moving to
SF.

How would we remap:

  http://www.roundup-tracker.org/cgi-bin/moin.cgi/FrontPage

(aka wiki.roundup-tracker.org) to the new instance? We would be
migrating away from sourceforge and I am not sure who is running the domain:

 wiki.roundup-tracker.org is an alias for vhost.sourceforge.net.
 vhost.sourceforge.net has address 216.105.38.10

>== Preserving contributed code files
>Another detail: It is probably easier to extend Moinmoin to display
>attached files as code nicely, (maybe even with syntax highlighting)
>than doing this will Allura's SF wiki engine. Moinmoin can be extended
>by plugins and the options specialised-Moinmoin-Hosting or using a hoster
>would allow us to run MoinMoin plugins.

Fair enough. I don't know (and am not really interested in learning)
the moinmoin ecosystem. One python project is enough 8-).

On Mon, Mar 25, 2019 at 03:26:43PM +0000, Bernhard Reiter wrote:
> 
> Ralf, John, 
> so what do you think about the Waldmann-EDV offer overall?

I'm fine with both variants, a commercial offer and the conversion to
SF although I'd prefer SF.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com

== Directly showing attached code files
Testing reveals that this already works with the recent Moinmoin 1.9
release. (We are still running an old version.)

When using something like 
  {{attachment:example1.py}}
it will be shown with syntax highlighting.

== Choosing the way forward
Ralf, why do you prefer SF wiki in particular?

There really is a medium sized kind of work to transfer the markup
and it would be missing features like subpages and directly showing attached
code files.

To me the transfer work is an argument, as we probably will still have
to clean up. We could go to waldmann-edv and later still switch to
somewhere else
if Intevation would stop paying for it in the future. Right now this seems
to be less work for core roundup devs.

Ber said:
> == Directly showing attached code files
> Testing reveals that this already works with the recent Moinmoin 1.9
> release. (We are still running an old version.)

Very nice. Does it show line numbers along with syntax highlighting?
That makes it very easy to annotate the file in the body text of the 
wiki.

My $0.02 is to move to the moinmoin vendor you identified. As long as
somebody is ok picking up the cost. This is the easiest transition and
gets us the features (email etc.) that we want/need.

We can open a new ticket for conversion to SF wiki in case somebody
is looking to get involved and they want to scratch that itch. This
is a hedge against vendor lockin and can be used to document features
that we need in case we have to move the wiki content.

John wrote:

== Directly showing attached code files

> Does it show line numbers along with syntax highlighting?

It does, I'll try to find a public example.

For the line numbers (for code within the page) see
https://moinmo.in/HelpOnFormatting#SyntaxHighlighting
https://wiki.python.org/moin/HelpOnFormatting#SyntaxHighlighting

However the feature is advertised in the docs, but at least in
 one moinmoin instance I could not use it - maybe a small defect.
I'll inquire.

== Where to move 
> My $0.02 is to move to the moinmoin vendor you identified. As long as
> somebody is ok picking up the cost. This is the easiest transition and
> gets us the features (email etc.) that we want/need.

That is also my current favourite, and my company Intevation would
pick up the costs for now.

Should I present this to our development or users list as proposal to reach
more people?

> We can open a new ticket for conversion to SF wiki in case somebody
> is looking to get involved and they want to scratch that itch. This
> is a hedge against vendor lockin and can be used to document features
> that we need in case we have to move the wiki content.

We could, though Moinmoin as software package is more widespread than SF's 
Allura. For the markup Markdown probably has more pages than MoinMoin's 
markup, but the interesting part for the migration is in the special 
features, so I'd say that having this in the moinmoin structure is more 
future proof. So our ticket should have been to improve the existing tools to 
export from moinmoin to other markups and structures.

Hi Bern:

In message <201904040909.07234.bernhard@intevation.de>,
Bernhard Reiter writes:
>Should I present this to our development or users list as proposal to reach
>more people?

I would say put it on the users list stating why we want to do it:

  https support
  managed service so we can work on roundup and not infrastructure.
  ...

One question I forgot to ask, currently we require a magic password to
create an account on the wiki. Can we carry that over or implement it
if we end up in a wiki spam situation like we had before?

I would like to try native anti-spam tools/account protections but
retain the ability to lock down account creation if needed.

Have a great day.

Hi John,

> I would say put it on the users list stating why we want to do it:

will do, but probably in week 16.

> I would like to try native anti-spam tools/account protections but
> retain the ability to lock down account creation if needed.

The main wiki on moinmo.in right now went back to only allowing 
superusers to create accounts to fight spam.

Note Thomas Waldmann from waldmann-edv.de runs moinmo.in and 
he is a leading MoinMoin developer. This is good, as we can follow
the current stable version of what the software as to offer.
My understanding is that we say which spam protection we want (from the ones 
that are implemented in moinmo.in). I'd ask him for advise when we do the 
move.

[x] Email to roundup-users send.
[x] Inline display of attached source files works (with line numbers)
    with current 1.9 Moinmoin versions. (The problem I've mentioned
    was me making a mistake.)

[ ] Wait a few days for comments.
[ ] Notify Waldmann-EDV that we accept their offer
[ ] Find out who can change our DNS (Richards Jones?)
[ ] Check for additional plugins (probably none)
[ ] Check that we and our theme works on MoinMoin 1.9 (hopefully)
[ ] Cleanout spam-pages
[ ] Cleanout or think about how to cleanout (spam) users
[ ] Give clean copy to waldmann-edv
[ ] Plan migration with everyone involve
[ ] Migrate
[ ] Announce migration
[ ] Enjoy better wiki! \o/

Hi Bern:

Where are you with this transition?

I was going through the docs and we still use http in the wiki address.
Getting that changed to https would be nice and IIRC that was one 
advantage of your plan.

-- rouilj

Hi John,
thanks for the reminder.
This got stuck because of other works.
Will resume as early as I can.
Bernhard

[x] Wait a few days for comments.
 
There we no further comments -> Move to Waldmann-EDV is adopted.
Send an email to Thomas Waldmann.

[x] Notify Waldmann-EDV that we accept their offer


[x] Find out who can change our DNS (Richards Jones?)

Yes, it is Richard.
(Documentation: 
https://sourceforge.net/p/roundup/mailman/message/36228730/ )


[ ] Check for additional plugins (probably none)
[ ] Check that we and our theme works on MoinMoin 1.9 (hopefully)
[ ] Cleanout spam-pages
[ ] Cleanout or think about how to cleanout (spam) users
[ ] Give clean copy to waldmann-edv
[ ] Plan migration with everyone involve
[ ] Migrate
[ ] Announce migration
[ ] Enjoy better wiki! \o/

For the details of implementing the decision
I think it is better to have a fresh issue2551045.

Add yourself to nosy there, if you are interested.

restoring new issue title

The decision was taken to move our wiki to waldman-edv,
issue2551045 tracks the implementation of this decision.

Thinking about it, this issue can be closed.