> - Profiles - the core is already integrated, but there are probably > loose ends to clean up. Also not clear how much testing its gotten.
0 - no strong views at this moment > - Sequence Diagram reimplementation? - sounds like we've got at least > a couple of votes for this -1 - I think that sequence diagrams should be merged to trunk but I don't think we should rely on it being ready for release in time for 0.26. It can remain disabled if need be at time of release. My current assumption is it will not be ready. > - Multi-file support? - I did the basics to support the profile work > and it probably wouldn't be a lot of work to enable it for general > use, but I'm loathe to contribute any significant new functionality > until the license issue is resolved +1 - I think we want to continue to improve our support for AndroMDA users and I gather this would be of major benefit. > - Scalability? - currently sucks for very large projects. Not clear > how much work it would be to improve. Could be one or two critical > bugs or a more general malaise. +1 > - Dependency cycles? - not a user visible item, but it slows our > refactoring and improving the code base, as well as our ability to > work well in the Eclipse environment 0 - I'd like to see a piecemeal approach rather than do a complete reorganisation before the next release. Moving kernel from src_new to its own eclipse project under src would make a good start as that is the one part that should definitely not have and reference to the rest of ArgoUML. > - Quality? - We've closed 67 unique, previously reported issues (126 > total including duplicates and bugs that we introduced post-0.24) and > we have 421 defects open (2 P1, 4 P2, 364 P3, 51 P4 & P5. We could > make a push to close a bunch of bugs (or triage them all better and > close some number of high impact ones). +1 - we need to review what P3's we think should require any further attention. > - ???? - insert your theme here. Suggestions? Heap space problems. I've seen several issues that appear to be caused by memory faults during save of project (caused I think by the zipping process tipping the balance). Loss of saved projects seems to be due to this more than any other reason. Apart from this our persistence seems quite stable (or at least was in 0.24 - I'll get back to that later). I was thinking of trying to implement a memory monitor running in a background thread that will update a meter in the status bar to indicate how much heap space is used/available. Not only would this give an indication to the user that his project is growing too large for the project but we could also prompt the user after load of a large project that they should restart ArgoUML with increased heap space before working on that project. We could also check heap space before a save and force the user to save as .uml if heap space is low. Back to stability of saving a project. We have had a few reports of problems with persistence which appear to have become resolved. But there has still been some suggestion that detail of an old project is remaining in a new project. I wonder if introduction a the progress meter and cancel button has introduced some problems. I think that means we now have another thread running for loading the project and updating the model that is maybe introducing race conditions. Linus - back to the licence issue - have you contacted the SFC for any advice? Regards Bob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
