On 3 December 2012 13:20, Alexandro Colorado <j...@oooes.org> wrote: > On Mon, Dec 3, 2012 at 2:35 AM, janI <j...@apache.org> wrote: > > > I agree on a lot of the things. > > > > BUT do not forget that a lot of questions/problems also applies to an > > upgrade. > > > > - User interface will change slightly > > - Data loss is not acceptlable but the UTF8 conversion might have a side > > effect on some browsers > > - The tweaks in the current mwiki, will not automatically be present > after > > an upgrade. > > > > Which tweaks? > If I knew then I could include it in the new version, problem is that a.o. imicat tells that there have been made modifications, and none of it seems to be documented.
The same goes by the way for all configurations, they are not documented, so I have to do compare. > > > > - we do not know if the extensions will work (in the same way) in the new > > version. > > > > Have you done the research or you are just speculating? Which extensions > hasn't been updated to the current version? any similar extension? > I have done some research, but not to the full extent, that will be done when we start upgrading. I see no need to do it, before we start the upgrade. To me that is only one checkpoint in a long list, we have to work through when upgrading. > > > > - there are no "the wiki", there are and will always be different systems > > out there. > > > > For the most part mediawiki is the most popular wiki out there and it's > markup the more widely spread among floss projects that I know off. > I might be, I have seen no statistics to support the statement, and some of the big wikis seems not to use mediawiki. Important is that the markup language is spread to other project, that would make a change easier But since the idea has already got a -1 its dead. Jan I. > > > > > > The argument about the text is very valid, but I think that the new > version > > also offers new facilities, and hope that all old facilities are > unchanged > > (but there are no quarantees). > > > > My intention was simply to make the community aware of the possibility. > > Because at this point in time I see the upgrade as also being quite a > > hurdle. > > > > Jan I. > > > > On 3 December 2012 06:49, C <smau...@gmail.com> wrote: > > > > > On Sun, Dec 2, 2012 at 11:35 PM, janI <j...@apache.org> wrote: > > > > JSPwiki just announced a new version: > > > > > > > > http://incubator.apache.org/jspwiki/ > > > > > > > > since it is a apache project, should we consider upgrading to jspwiki > > > > instead of continuing with mediawiki ? > > > > > > > > The upgrade will almost for sure be harder, but to me it seems > > beneficial > > > > to use products from our own "family", that way we help them and they > > > > hopefully help us. I am also confident that it can be done without > data > > > > loss, which is an absolute no-go to me, we will not accept data loss. > > > > > > > > If it is decided to go down this path, I will contact jspWiki and get > > > > involved with their work so we have a real influence on how the wiki > > > > software evolves (especially in regard of spam control). > > > > > > While certainly possible to convert from one wiki syntax to another, > > > it's no small feat... and that's if the source wiki uses only standard > > > syntax for the source Wiki. > > > > > > The current MediWiki implementation has a significant number of pages > > > that rely on extensions for their content. To have a successful > > > conversion, you are looking at needing to rewrite thousands of Wiki > > > pages. Not necessarily to have 1:1 conversion, but simply to ensure > > > that the information is still presented in a logical manner (I'm > > > thinking of the documentation pages for example). > > > > > > Before anyone should really consider this, you need to gather up a > > > sizable collection of dedicated volunteers who are willing to sift > > > through every wiki page and validate the content, fix the broken > > > content, correct conversion errors, and reconnect the information > > > flow. > > > > > > You also will need to account for custom written extensions and the > > > functionality (although simple) they provide. > > > > > > It's a very big job to convert even a small number of pages.... > > > > > > Clayton > > > > > > > > > -- > Alexandro Colorado > Apache OpenOffice Contributor > http://es.openoffice.org >
