KIELER Meeting 2009-10-23
- moderator: haf
- protocol: oba
Topics
Poster
- all in all it has been a very nice poster, just small changes necessary (msp will change them)
- cmot presents KIELER using the poster, he is asked what the profit in reimplementing KIEL to KIELER is. Is there anything what KIELER can but KIEL could not? Sure! KIELER has model comparison and environment visualization.
Release I - 3.5.0
We will need branching to have KIELER versions, adapted to particular releases. Thus cf. the branching tutorial by msp below.
Reviews
From now on we will have code reviews (besides the usual design reviews) with the purpose of increasing code quality. The basic idea behind this is that we want to build a base that enables sharing of experience and learning from another.
At the time of a code review, the code to be reviewed should have:
- no exceptions
- no warnings in Hudson
Important points about the code review process:
- The process should be fair, meaning that one should not always be the reviewer or always be reviewed.
- It is in your interest that you profit from others experiences thus it should be also in your interest that your code is reviewed so ask for it; even if your advisor looks like he had enough of reviews, you still should want your code review because it is their job to give you this assistance - said by Hauke himself:)
- only reflection not problem solving during a review!!
- documentation in trac, similar to design reviews
Coming code reviews:
code by <-- reviewer Notes cmot <-- haf, tam mim <-- msp, sku oba <-- cmot, chsch in December or end of November
Possible order of events in a code review:
- Two at most three people work about two hours on a code review (including the time needed to break into)
- The one, whose code is being reviewed, takes notes on a (seperate computer for example..)
- At the end they prepare a ticket with the summary of things to be changed etc., i.e. with everything what is to be done yet. But this is not a must for preparing tickets could be much of an overhead sometimes.
About FindBugs warnings in Hudson:
- Hint: If FindBugs finds bugs, you do not consider as bugs or possible error sources, then you can supress warnings in a very detailed and purposed way.
- If you there are known but unimportant or supressed warnings, you should always document them so that there is no redundant questioning in the code review later.
A smaller team will decide on the set of necessary warnings in FindBugs:
- Tasks are to take a look at the points, checked by FindBugs and decide which one to deactivate. Additionally we should ensure that everyone uses the same FindBugs configuration.
- This should happen before the code reviews. Our FindBugs team is: rvh, msp, haf, chsch
ONCE WE HAVE AGREED ON A STANDARD, CHSCH WILL ACTIVATE AN EVALUATION SYSTEM BASED ON POINTS. THE WINNER WILL GET A PRESENT IN OUR CHRISTMAS PARTY !! =)
no Graphviz
Problem: How do we proceed when the user does not have GraphViz (GV) installed?
Suggestion 1: Supplying as a bib --> technically not possible
Suggestion 2: Supplying as an exec --> we could bundle GV into our product by putting its binaries (for each platform) into a plug-ing, is this CPL - conform? Ask GraphViz people if that's OK in terms of the licence --> Ticket #362
- Works this technically? --> Ticket #363
Threads
Problem: In the moment all Visual Management effects are in the same thread because of the restrictions of the EMF Transaction framework. This causes an illegal state exception resulting the desired visual effect, say auto-layout, to be discarded if our diagram is in an read-only status.
Use Cases: This conflict happens if for example the auto layout is not called by pressing its button but programmatically thus it is not necessarily a problem of VM only. It also happens when parsing the labels for instance. What we need is a global concept for threadening, the solutions at the moment are ugly hacks like endless-looping until the exception is gone...
Suggestion 1: Is it possible to proceed the other way around, i.e. that the transaction registers itself to the layouter?
Suggestion 2: Are there any listeners that listen to the models and tell when it is writable? msp will look for some kind of listener interface for EMF transactions. --> Ticket #364
Branching in SVN
by msp
Please refer to the brancing user guide, Miro has prepared for us.
Use Cases for branching in SVN
- trunk should actually consist of the most up-to-date code but sometimes we have to make major changes to our plug-ins. Thus in that time, our code is erroneous and instable for it is under construction, so to say. In this case, we would branch to keep trunk clean and make auto-build go on.
- releases should contain stable code so we will construct branches and put our stable versions in them for each release. Thus in a release-brunch the unstable features are taken out of plug-ins and there is only stable code.
Some notes about branches in SVN
- branches consume a minimal amount of memory because our plugin is not copied to the newly created branch, the branch only needs the URL of its corresponding trunk directory..this way it can access the code in the trunk when needed. It also registers some meta-data about the changes made by the author but the whole code is not copied.
- branches are visible to other users thus also accesible
- The version numbers do not increase by one at each commit for each commiter. But they are universally unique in a repo and are always monotonous.
