MMBase
Homepage / Contact / Technical Board

Back to overview

Technical Board: 2006/03/06

(for English translation see below)

Verslag derde vergadering technisch comité MMBase.

Vergadering gehouden te Hilversum,. Stichting MMBase.

Aanwezig: alle leden:
Nadia Poulou (Kennisnet)
Ronald Vendelmans (Amsterdam)
Jean-Luc van Hulst (Finalist)
Henk Hangyi (Mmatch)
Daniel Ockeloen (MMCoder)
Michiel Meeuwissen (PO)
Jo Lahaye (stichting).

Er zijn geen opmerkingen over het vorige verslag. Jo zal dat op enige punten aanpassen en publiceren. Omdat bijna alle onderliggende stukken Nederlandstalig zijn, is het niet eenvoudig de notulen in het Engels te houden, maar er zal gepoogd worden in elk geval op de website e.e.a. kort te beschrijven.

1. Releasebeleid.
Naar aanleiding van de vorige vergadering wordt Jean-Luc verzocht zijn stuk enigermate te herschrijven, zodat wat duidelijker is welke taken een releasemanager op zich behoort te nemen. Jo zal het voorstel aan zijn bestuur voorleggen, maar geeft aan dat dit in lijn met de prioriteitstelling is. Bovendien heeft een dergelijke functie twee jaar lang in de begroting gestaan. Deze is er uit gehaald om dat er in die jaren geen consensus over kon worden bereikt.

2. Michiel geeft aan dat om 1.8 te kunnen releasen er vooral nog een groot aantal bugs gefixed behoort te worden. Er wordt afgesproken een bugfixing day te organiseren en dit op de developersmeeting voor te leggen. Daar wordt afgesproken dat deze dag op vrijdag 24 maart in Rotterdam op kantoor van Finalist georganiseerd wordt. Jo zal contact opnemen met het management van de Publieke Omroep om te vragen of het mogelijk is Michiel aansluitend een tweetal dagen vrij te stellen om de release ook daadwerkelijk af te ronden.

Gepoogd wordt om dit moment tevens aan te grijpen om Jira als bugtracker te installeren. Jean-Luc zoekt uit wat hiertoe de condities zijn. Een dump van de database en de contactgevens van Justin zullen naar Nico gestuurd worden (actie Henk).

3. In de tweede vergadering van het technisch comite is uitvoerig gediscussieerd over de vraag hoe te komen tot een architectuur. Het plan bestond om eerst uitgangspunten te formuleren en een soort ‘mission statement’, maar de aanwezigen denken dat de systematiek zoals die door Nadia Poulou van Kennisnet wordt gepresenteerd, waarschijnlijk sneller en makkelijker tot een compleet architectuurplaatje leidt. Deze systematiek laat zich in a nutshell als volgt beschrijven.
Er zijn drie architectuurniveaus te onderscheiden:
1. organisatie
2. applicaties/services
3. technisch
Bovendien geldt voor ieder ‘onderwerp’ dat van belang is voor de architectuur dat het op geuniformeerde wijze beschreven behoort te worden (bijvoorbeeld: licentie, platformonafhankelijk, coding standard, documentation standard, etc.).
De leden van het technisch comité maken per omgaande een start met het beschrijven van de principes, conform het sjabloon dat daartoe is opgesteld. Dit geheel leidt tot een set van documenten, die tezamen het architectuurmodel representeren. Afspraak is dat we hier al voor de volgende vergadering een eind mee proberen te komen. Nadia biedt bij deze notulen de presentatie en het daarin opgenomen tijdschema aan.

Deze ‘principes’ worden niet in beton gegoten. Ieder principe heeft een eigenaar. Principes kunnen bediscussieerd worden. Gezocht wordt nog naar een goede systematiek om dit te faciliteren (wiki, sharepoint, anders).

4. Communicatie.
Voor de volgende vergadering zal Jo een communicatieplan opstellen. Als we het schema aanhouden zoals dat door Nadia voor de inhoudelijke bijdragen is opgesteld, dan lijkt het zinvol om bijvoorbeeld in mei de developersmeeting een wat uitgebreider karakter te geven en daarbij ook de gebruikers en dienstverleners uit te nodigen. Er is dan wel een en ander te melden.

5. Karma en Didactor-systematiek.
Dit is uitvoerig besproken op de developers meeting en de vorige keer in het technisch overleg. In de komende periode moet een aantal kleine en gerichte sessies met belangrijke stakeholders leiden tot meer concrete voorstellen. Belangrijkste doel is om invulling te geven aan een modulaire component gebaseerde ontwikkeling en het bereiken van synergie tussen beide belangrijke ontwikkelingen. En uiteraard om ervoor te zorgen dat beide ontwikkelingen daadwerkelijk geïmplementeerd kunnen worden. In een latere fase zal brede afstemming plaatsvinden.

Jo Lahaye,
7 maart 2006.

-----
(English translation, with thanks to worldlingo.com)
Report third meeting technical committee MMBase.
Meeting held at the MMBase Foundation, Hilversum

Present: all members:
Nadia Poulou (KennisNet)
Ronald Vendelmans (Amsterdam)
Jean-Luc of Hulst (Finalist)
Henk Hangyi (MMatch)
Daniel Ockeloen (MMCoder)
Michiel Meeuwissen (PO)
Jo Lahaye (Foundation).

There are no comments concerning the previous report. Jo will adapt that on some points and publish. Because almost all underlying pieces are Dutch-speaking, it is not simply keep the minutes in English, but there will be attempted anyway on the Internet site e.e.a. to describe.

1. Releasemanagement.
As a result of the previous meeting Jean-Luc are requested its piece rewrite enigermate, so that what is more clear which tasks releasemanager in itself belong take. Jo will present proposal it to its governing board, but indicates that this is in line with the definition of priorities. Moreover such a function has stood for two years in the budget. These have been obtained from for that in those years no consensus could be reached.

2. Michiel indicate that 1.8 to be able release there especially still large numbers of bugs of gefixed belong become. There bugfixing it is agreed organise on the developersmeeting day and this to present. There it is agreed that this day on Friday 24 March in Rotterdam on office of finalist is organised. Jo will get in touch with the management of the public broadcasting to if ask it is possible Michiel a connecting pair put days free to wind up the release also effectively.
Is attempted to seize this moment tevens to install Jira as bugtracker. Jean-Luc zoekt from what for that purpose the conditions is. A dump of the database and the contactgevens of Justin will be sent to Nico (action Henk).

3. At the second meeting of the technical committee the question how to reach an architecture has been exhaustively discussed. The plan existed to formulate mission statement firstly main points and a type, but the people present think that the system is presented such as those by Nadia Poulou of Kennisnet it is presented, probably faster and more easily to a complete architecture blade leads. This system can be described in a nutshell as follows.

There are three distinguish architecture levels:
1. organisation

2. applicationsservices

3. technically
moreover applies to every `subject that is important for architecture that it belongs become on geuniformeerde manner described (for example: licentie, platformonafhankelijk, coding standard, documentation standard, etc.).
The members of the technical committee make by handling a start with describing the principles, in accordance with stencil key set that has been established to this end. This whole leads up to a set of documents, that together represent the architecture model. Appointment is that we already for the next meeting an end to try come. Nadia offer at these minutes the presentation and in this the taken timetable.
These `principles are not poured in concrete. Every principle has an owner. Principles can be discussed. Strained becomes still to a good system this (facilitate wiki, sharepoint, differently).

4. Communication.
For the next meeting Jo will draw up a communication plan. If we apprehend the diagram such as that by Nadia for the substantive contributions have been established, then it seems significant for example in May the developersmeeting to what vaster character to give and thereby also the users and service providers to invite. There is or and communicate an other one.

5. Karma and didactor system.
This has been exhaustively discussed on the developers meeting and the previous time in the technical consultation. In the coming period a number must small and specific sessions with important stakeholders lead to more concrete proposals. Most important aim is to interpretation to a modular component based give development and reaching synergy between both important developments. And of course to ensure that both developments can be implemented effectively. At a later stage broad harmonisation will take place.

Jo Lahaye,
7 March 2006.