The biggest planning item is prioritization. Who is going to stop doing what they're doing and work on UML 2 instead? If no one's going to do the work, no planning is needed. Those who are going to make it a priority can then get together and do the planning.
The very first thing on the wiki planning page is "pick a release date." That's simply not possible at this point, so isn't even worth discussing. Similarly the task list reads like something out of a Microsoft Project or some other project management tool with dependencies, percent complete, etc. Most fine grained dependencies aren't going to be known until someone starts doing the work. Things are either "done" or "not done", so %complete is 0% or 100%. If you want percentages which aren't tied to specific user functionality, just run the JUnit tests using the eUML subsystem and see what percentage pass. I do think it's valuable to discuss and agree on overall goals. What is it that you are trying to achieve? Who are your customers? From my personal point of view, if you aren't going to upgrade ArgoUML UML 1.4 projects or if you're going to reimplement large chunks of functionality anyway, you should consider basing your efforts on Papyrus or Topcase-d or another open source UML 2.x editor and save yourself some time and effort. >From a work organization point of view, I believe that diagram by diagram is exactly the right way (and I told Bogdan the same thing when we were planning the 2007 work as well as mentioning it to a GSoC applicant last year http://markmail.org/message/rqzxp2a43tfetv2s). Vertical slices are a much better way to organize things than horizontal layers. Users don't care about "subsystems." Diagrams are things that they can see and use. I think the Use Case diagram is pretty much done. The Class Diagram should be the next focus from the point of view of usefulness to users, but if someone has a burning desire to do, say, the State Diagram, I wouldn't want to discourage them. The Sequence Diagram was just redone, so presumably that's pretty much fully UML 2 compatible and we just need to finish up the underlying plumbing. In keeping with the verticality theme, I'd say that the Undo framework should be chosen and implemented up front so that as each new command is implemented the corresponding undo can be tested as well.I think, but am not 100% sure, that there are currently got two different Undo frameworks, one which is eUML specific and one which is tied to GEF. BTW, the same vertical vs horizontal thing applies to property panels. If people are dead set on reimplementing things, it would be much, MUCH more valuable to have a even just a single property panel implemented for UML 2.x and UML 1.4 (and perhaps SWT & Swing) than to have all existing property panels reimplemented with no clue as to whether or not this was going to help you move forward into the future. I know I said that before, but it bears repeating. The eUML work that I did recently was basically to repair things that got broken when I added support for read-only extents/models for the profiles and to implement missing functionality required for an OMG UML 2.x interoperability test that I wanted to participate in. I also cleaned up the copyright notices which reference "The ArgoUML team" to instead reference a legal entity "<initial contributor> and other contributors." As an aside the eUML subsystem uses the New BSD license which doesn't reference the U. of California Regents since I didn't see any point in starting an entirely new subsystem which continued the past's bad habits, but moving forward, if I'm able to spend significant time on it, my copy is going to switch to EPL. This probably isn't an issue since I've been the only one working on it, but just wanted to be up front about it. On some other topics which were mentioned: Explorer - The Explorer view is not strongly tied to the meta model structure. It uses collections of rules to organize the different perspectives. If there are places where the existing rules don't match up, new ones can be written and the default contents (they are user customizable) for each perspective defaults chosen based on the metamodel. Property Panels - The reason property panels throw lots of exceptions is that a) they use a lot of the Model API and b) the way that I stubbed out the API in May 2007 was to have everything throw a NotYetImplemented exception, because I wasn't confident in the test coverage and wanted it to be obvious when you used something that wasn't implemented. If people would rather have things not throw exceptions, that's an easy change to make, but I don't personally consider it an issue that importing XMI files with unsupported elements cause errors. When you find a test file that doesn't work, implement the missing functionality so that it does. OK, that's kind of rambling, but I don't have time to go back and edit it into a coherent whole. I'd suggest that anyone who wants to work on this, pick a test and get it to pass or pick a diagram and implement some functionality. After you've done a few days work, you'll have a better understanding of what's needed. Tom ------------------------------------------------------ http://argoeclipse.tigris.org/ds/viewMessage.do?dsForumId=5521&dsMessageId=1499284 To unsubscribe from this discussion, e-mail: [[email protected]].
