COSMOS PostMortem 1.0

This page captures the thoughts of the community on what went well in COSMOS 1.0 and what needs to be improved on going forward. Note that we don't need an entry in all of the categories below, and please create a new category if that makes sense.

Meetings

1. Meeting chair also takes the meeting minutes
   1. It slows down the meeting when the chair says, "Hang on a second, let me note that down." Proposed from David Whiteman: rotating meeting minute taker. Everyone has a turn.

Development process

1. Review and discuss the blog post discussing the Eclipse process and whether it is truly Agile. Most of it is really dealing with whether the process is enforced. Let's look at our project and see if we follow all of the 10 guidelines listed, and whether we need to change anything to help with that.

Documentation

1. Consider whether, in the absence of a doc writer, we want to look at the wiki-to-eclipse-help converter described here. Of course that would mean we would need to get our docs moved from the current HTML location back to the wiki, but going forward that might make it easier for all of us to maintain the docs. If nothing else, it's something for SDD to consider since they don't have their user doc written yet.

Legal

1. Do we want to segregate code that has pending legal approval in a separate zip file and add it into the main zip file once it's cleared Legal? Proposed from David Whiteman: attach 3rd-party dependent code to bugzilla until legally cleared.

Architecture or development

1. One thing we did with the SDD tooling team was hold a code review for their initial COSMOS contribution. I would suggest we consider doing that at least once for other areas of the project in the 1.1 timeframe, time permitting. Code reviews are an excellent way to level set everyone on our coding practices, and many defects are proactively discovered during those types of sessions. They can be tedious, and are typically not the most fun for the person whose code is being reviewed, but the improvements to the code base and the developers themselves make them worthwhile. One way to contain code reviews to a tolerable timeframe would be to review pre-selected snippets instead of tackling the full codebase.

Testing

1. Do we want to change the COSMOS dev process so that a person is forced to update a test case, or add a new test case, when a new feature is added? (Excluding doc features.)
   1. If yes, how can we automate a check for this? Build? Extend CVS check-in wizard?
   2. If not, what alternative to ensure test coverage of all COSMOS code?

Minutes for the postmortem meeting Dec 10, 2008

Att: Saurabh, Ruth, David

Legal

• Saurabh, only had some concerns about the legal issues. For example, if we are seeking clearance for a JAR and suddenly we don't have legal clearance for that, we have to remove that JAR from the build and it breaks the whole code.
• Three stages: zero approval goes into bugzilla, parallel IP approval goes into CVS, full approval, do whatever you want.
• parallel IP approval, can't release it. Can try to make it quarantined in separate plug-ins or folders in CVS and then move it around whenever we want to reunite it with the code base. If keeping it separate will break the code, that in effect makes it all "in parallel". Whenever we make that exception, we have to understand that risk.
• developers responsible for keeping code that depends on parallel IP approval in separate plug-ins or features. Affects Build in how the zip files are built.
• going forward, when you get approval, when you create your CQ in IPZilla, once you get parallel IP approval you should create some sort of segmentation between references to those libraries and the rest of the code base. Development also has responsibility to notify the build team when a new zip needs to be created, even if it's for just one plug-in & feature. We do package a lot of code as plug-ins but a lot of the code doesn't run in Eclipse such as DOJO and SDD. (SDD runtimes are not Eclipse plug-ins, not sure about the SDD tooling.)

Meetings

• SML group has the rotation but you have the option of saying that you won't be there. Chair just switches the order of the names.

Development

• each subproject to check that and if a subproject thinks that something doesn't work for them, bring it to the community call to document it in the COSMOS dev process
• more of an awareness thing. Ruth proposes that we have a checkpoint at each milestone, check the 10 guidelines and are we doing it.
• Eclipse process in general isn't Agile. But in the case of enforcing how COSMOS follows the Eclipse process, need to ensure that it's followed up on such as writing good tests. Rather than a vague checkpoint saying "check this", we need to list those specific items checkpoints.

Documentation

• Ruth expressed concern about wiki. Need to track contributor and it's easy when it's a HTML attachment to a bugzilla, but with wiki it becomes manual addition to the IP log, which is painful.
• Also copyright docs but not the wiki? Not true, can be EPL or other, and can copyright the wiki. But anyone that has a bugzilla id can edit it, and the build checks the copyright dates of the docs as well as the code but not the wiki.
• other strong reason not to consider is that it would be a significant time to convert everything back to the wiki. Until the point where there's a large community with frequent changes to the documentation, and perhaps a dedicated tech writer, it makes sense to continue with HTML for now.

Architecture or Development

• need to discuss with Jason and Jimmy

Testing

• need to discuss with Jason and Jimmy