As lot of time passed, we are going to backport from 1.10 the tested improvements, in more than moving mods to mods.

Sunday 25th october is the planned deadline for adding stuff into BRANCH-1-9, then we can quickly debug on new features added and improvements.

After that date, nothing, and really nothing should be added and the only activity expected on 1.9 should be about debugging existing stuff, as well as translating. Then we expect to be able to release the 1.9dr4 on november 1st. That release is aimed at developers and translators only and should not be used in production environment.

2 weeks will be necessary for fixing the last translations and work on documentation as far as possible. Then we can have a final 1.9 Release, with a good stability level, around sunday 14th in november,

The mods feature make possible to split the updating of tikiwiki in parts, by using http://mods.tiki.org as a reference provider of new features for testing or using in production. The mods installer is almost done and is the priority for the 1.9 release, as well as the tikiproject feature that will manage the project aspect and the publication side of each subproject development.
That mods feature is expected to work in a way similar to portage or apt : a remote server is used as a reference for getting index of new available features, plugins, themes, whatever. A set of metafile will handle the operations to be done at install and at removal, in SQL statements, scripts and configuration options.
The mainstream server would be mods.tw.o for spreading the tikiwiki community development, but arbitrary servers can also be used to manage self-publication of new features, or even internal releasing of home-made features in a network, intranet or VPN.
The mods is not following the branches schemes, as many features are not depending on the version used. An extensive documentation on the Mods system will provide proper information about how it's working.

The tiki-project feature, developed by damian, will be ready before the freeze (this sunday) and will be able to handle the sub-group development on specific features or addons in tikiwiki. The main goal is to reduce the tikiwiki mainstream tarball to a lighter profile, and puts all the optional and one-time used features in mods. Of course we need to discuss about what will go in mods and what will remain in tikiwiki main trunk.
Here is a list of features that we think appropriate to move to mods before 1.9 final release.

• TikiSheet, that also contains licence doubty libs, and is still in development
• Wikigraph plugin and graphviz lib (also subject to licence diff)
• Galaxia is a big chunk and is quite independant, it should go to mods
• phpCAS feature is also independant, and very specific in its use as you need a special server environment
• maps_ feature requires as well some special server setup and is not useable by everyone, that should go to mods
• the homework feature is maybe appropriate to move to mods, but that's not decided yet
• the themes are numerous and should be limitied to a small number of theme into the core release. The mods is very adapted to distribute more and more themes.
• Most languages supported should move to mods as well, depending their level of completion. Actually the languages should deserve a dedicated module in the cvs, Ultimately all languages should go to mods.
• fonts for pdflib are heavy and not necessarly used, and we can have them in mods too, except one that would be the default one (probably helvetica).
• tiki jukebox needs to be finished and will become a mod.
• ... if you think about some more, please suggest them below...

• Import phpwiki and other import filters are used only once usually and could be installed, used, and then uninstalled.
• the SQL upgrade scripts are one-time used, they should go to mods, as the mods feature can execute sql queries as well as phpfiles. the main advantage is that it enables the possibility to downgrade tiki (which is not very easy right now)
• the converted database files can also be in mods, as most of time they are not used (in regard of the proportion of mysql users compared to others in tikiwiki population)
• ... if you think about some more occational features, please add them below...

What remains in tiki main trunk and requires an intensive attention in next days, in more than the declared bugs on ReleaseProcess19 as well as in sf bugtracker.

• rewriting of htmlMimeMail lib (or getting agreement from author for use in an LGPL release). If rewriting is done, mose will handle it.
  • Marc contacted the author that said it was a BSD licenced lib, so we have no trouble and can keep it !
• replacement of Date and Netsocket libs (a rumour says redflo could handle that)
• replacement of POP3 GPL library
• we need to be sure that all help-links point to a valid page, by at least changing them to go to valid pages on tikiwiki.org (everyone is invited to help on this, that's not high level technical work, just a matter of changing some urls in templates).
• the search feature had some recent improvement (about permissions checking) and it needs to be tested extensively (batawata did work on it, we need more eyes to test and validate it).
• we need to have http metadata more fitted to the actual content of each page (eg. page description for wiki pages, heading of articles can be in meta description) damian plans to work on that.
• we need to know what have been done in quizzes features and check if it's useable. ggeller worked on it, his input is primary on there, but he worked with dgd that now uses moodle, we think that the motivator is not so intense anymore)
• FAQ needs a per-item permission handling, which is easy to add, and very useful. either mose or damian will manage that trivial issue.
• we need to check up the permissions handling into multiprint and pdf generation features.
• ... if you know more issues, please list them below ...

• polls feature has got some enhancements by mose
• gary (gg) have hacked the calendar for adding the possibility of events management, where people can attend, and get notices by mail. Quite nice work, and at last the calendar will evolve with some new blood.
  • Gary committed his work, please test it and feedback !
• ... if you think about some more, please suggest them below...

The third party libs need to be upgraded to recently released version

• smarty
• adodb
• phplayers
• jscalendar
• ...

• we need a review of what have been uploaded the recentlly, to see in the week what can jump into 1.9 or in mods

• we absolutely need a rationalization of the comments include, which is used by forums as well as for comments. It needs to be split, and comments, as the categories, deserve a specific code not linked to forums.
• the tikiMarket project is a special workshop, that could enable the community matching between wishes and offers, possibly but not necessarily involving hard cash transfers and third party referee. It includes the necessity for a voting system for taking in account the biggest part possible from the community.
• The wikifarm is an old idea but still very much wanted.

-- mose and damian with the help of Berryweb