What's that expression again? Luck is what happens when preparation meets opportunity. I was reminded of this cliche recently while reading The Last Lecture by Randy Pausch (a must read). How lucky are you? To be prepared, I think you need to have a plan.
I've been spending a lot of time planning lately. So much that I've had little time to come up for air. In addition to looking at what I'd like to release in the next versions of ER/Studio, ER/Studio Enterprise Portal, and other Embarcadero products in 2009, I've been looking at what will be part of next year's incarnation of MDT as part of the Galileo simultaneous release in June.
Plans for Eclipse projects were due yesterday, and I'm pleased to say that the MDT component leads were able to pull together plans for the MDT components just in time. There's a new, standard format for plans now, which I think is a good thing. One of the nice aspects of the standard plan format is that much of a plan's content can be populated dynamically using Bugzilla queries. Projects like EMF have been doing this for years; I'm glad that more projects will now be able to take advantage of this time-saving approach to planning.
Unfortunately, one of the not-so-nice aspects of the standard plan format is that much of a plan's content can be populated dynamically using Bugzilla queries. I'm cool with the notion that a plan is a "living document", and that using Bugzilla queries allows plan items to transition from "proposed" to "committed" or "deferred" without having to update the document. But this approach also allows bugs to be added and removed from a plan without an easily consumable record of these changes or why such decisions were made. Where's the accountability? In my mind, a plan is not just a document that you can point to at the end of a release to say what you ended up actually doing - that's what release notes are for.
One of the challenges I encountered early on while trying to put together the plans for my MDT components was the desire to view a plan after a release and have it still accurately reflect what was originally planned. Depending on how the Bugzilla queries in a plan are written, it seems that items (particularly ones with version-agnostic target milestones like "M6") which are on the plan for one release could conceivably disappear from that plan and reappear on the plan for a subsequent release. In the absence of the ability to assign multiple target milestones in Bugzilla (one of the features of JIRA that really like) I realized that I needed a way to tag a bug such that it would always be affiliated with the plan for a given release.
I proposed the introduction of a 'galileo' keyword (for bugs that are part of the plan for the Galileo release), but some folks were concerned about the proliferation of keywords (because they are global elements in Bugzilla). Then Denis suggested an even better idea - a 'galileo' flag that could be made available only for projects that wanted/needed it. As it turns out, it's quite a useful thing. Not only can I now tag bugs as being committed (galileo+) or deferred (galileo-) items on my Galileo plan (in perpetuity), I also have a way of marking bugs that get fixed in the Galileo release but weren't originally on my plan (indicated by the absence of the 'plan' keyword). Thanks, Denis!
PapyrusUML: Papyrus UML support in Hawk
14 hours ago