Development Tracks : update changelog

We need an inventory of all changes in HEAD from the last 6 months. Many changes have not been reported and we need a good changelog. The Inventory takes place on http://tikiwiki.org/ReleaseProcess19 and is subdivided by sections/features.

Quality Assurance Watch : dogfooding trackers

Enhance the Sirius Quality Watch process by sorting the SF trackers to prepare tracker migration in the near future to a tikiwiki platform with new 1.9 trackers.
Here is the crazy idea :

  • we can use both trackers SF and tikiwiki, so they are leveled with a step of natural validation by transfer (or not) from SF to tiki tracker.
  • we should use Integrator (or that idea at least, if not the code) to build a SFtrackers Navigator, to prepare automatic feeding of tikiwiki tracker, maybe a cronned job can grab new tracker items daily from SF using curl. We could even have a tikiwiki SF user that closes bugs on SF and does the duplicate work (ultimately).
  • then, the tikiwiki tracker site becomes a tool to grab tracker items from SF and copy them into tikiwiki trackers with everything already filled but modifiable. Bugs could also be submitted directly in tiki.
  • tikiwiki developers will be sure to use better feed of sorted problems and maybe will collaborate more on fixing then. And non developers can contribute as well by managing the sorting and merging.

It solves some issues, when someone invests a lot of time in tracker without many resources to solve problems by himself. It is very ungrateful to work on something that nobody uses. SF trackers are not visited by the most active developers in tikiwiki community, they need to be more accessible, and then the sorting operation can be more valued (by effectively sorting/namespacing/merging and not only add comments to bug reports).
Such a tool will not be made in some days, and I need help of inspired people to dig with me in that direction.
Please show yourself.

I'm preparing http://dev.tikiwiki.org as a test platform for that Quality Project (as for doc.tw.o we'll slide auth from tw.o very soon).

We released in tikiwiki an internal help system that uses urls to http://tikiwiki.org (in 1.8.3 you can already change that base url, but not the names of linked pages).
Some of those expected help pages are inappropriate, empty, outdated, suspect, or just plain missing. We are legendary bad with documentation effort as a group, even if individual have spent some valuable time in http://doc.tikiwiki.org it's quite hard to compass the whole of tikiwiki in a single documentation process.
I would like to split the documentation effort into parts so it's more easy to digest. The first slice would be those pages that are linked from each tikiwiki release. It has to be a structure or a category of special pages with special attention on them.
I bet that a side effect will be to make those pages as central references for the rest of content on tw.o (we have now more than 1500 wiki pages there).
So, I wish to integrate the management of those pages in the release process, as those operations are interdependant.

We need tools for that work :

  • script to extract list of official help pages
  • scripts to retrieve all content of official help structure by many ways, to duplicate it locally, so it can be released at the same time as the source code tarball in a separate package, under creative commons licence.
  • a good effort on template for those pages. Maybe some work from doc.tw.o can be copied there
  • we need to add in next version an extra parameter in the link to doc with the version number
  • it could be nice to even have a new smarty plugin to mark content as belonging to that version or that other version
  • the multilingual has just been introduced in tiki by sylvie and is still under observation, but it can be good also to add a lang param if possible.

1.9 CVS Branch Freeze

A first Release Candidate will only manage the inventory of changes, and will provoke a feature freeze. When documentation will be integrated in the release processes it will be easier to add new features without adding more shadows. But in the while we need to strengten existing features with a decent intregration, including doc.
There is a question now about branching or not. I think we should begin a branch BRANCH-1-9 and declare that HEAD becomes the 1.10 development version for new features and risky experiments.
That would mark the start of the future stable Sirius branch, BRANCH-1-9. This proccess adds some complexity in the branching scheme, but if we keep it logical it can be followed.

The freeze will officialy begin on the 19th of June when the branch tag will be created.

First release candidate : saturday 19th June 2004

It will essentially focus on inventory and preparing the Quality process for further release candidates up to the final release that should occur when stability level will be satisfying.
I'll upgrade http://tikiwiki.org to 1.9rc1 as soon as it is tagged, and that website will help us as always to check if all goes as expected.
That release is not expected to be perfect, but it's a tool for contributors in translation and documentation that are not daily in cvs. I call it a Developers Release but Release Candidate is good too.


Note about Translation process and multilingual

As we can count on the motivation to have at the end a decent multilingual behaviour in Tikiwiki we should also prepare to engeneer the effort of translation on documentation in more than only managing application text.
The Feature Freeze implied in the Release Candidate makes possible the concentration on documentation and translation efforts. I would like to hear opinions from translators on the best way to organize that work to make it easy to maintain.

Note for developers on current integration of new features

Please contact me if you have plans or projects that need special attention in the 1.9 release process.
If in doubt, just remember that what is begun is to be finished on branch, and what is new will go to HEAD as always.
You have up to the 19th to clean up things, remove them, or protect them against abuse if they are not secure/safe.

Note about merges

That new branch will introduce a new merge procedure to avoid pain :

  • BRANCH-1-8 merges to BRANCH-1-9 instead of directly to HEAD
  • BRANCH-1-9 merges to HEAD to port fixes from 1.8 and from 1.9

About mods.tikiwiki.org

Now that we have the mods module in CVS, we can release a companion package with all mods under a mixed licence. Mods have the advantage of escaping many restrictions in the main tiki source tree and are adapted to wild contributions that are not perfect but still useful.
If you are hesitant to contribute in main tikiwiki source code, consider using the mods module in cvs to share anyway.



mose