I think it's reasonable to overlap 0.28 planning with the 0.26 end game, because it always take a while to get plans to converge.
I definitely think that the GSoC code needs to get integrated in a more timely fashion than last year. The release that we are doing now includes *last* year's GSoC profile work. The ArgoEclipse project will be doing a release incorporating Brian's work as soon as ArgoUML 0.26 is stable. More timely releases in general are key. I saw a blog post today claiming that ArgoUML was dead and not being updated any more. When there are no releases, no changes to the web site, news items are hidden behind a mouse click, etc, its a reasonable assumption and not a good one for the health of the project. A year should be the absolute maximum time between releases, but more frequent would be better. Work should be dropped from the release to make the schedule rather than extending the schedule to accommodate work. Doing a timely GSoC integration release is going to require a concerted commitment from both students and mentors. Those comments should be solicited and made explicit, not just something that's based on tacit assumptions the way we normally work. Anything which isn't supported by committed people or which can't make the schedule can wait for the next release train. The voting system is great in theory, but it's got a bunch of problems in practice. A lot of votes are from people who lost interest and wandered away years ago. Should their votes still count? It's also pretty clear from looking at voting patterns that not everyone realized they could cast multiple votes for a single item, so one person's 5/10 vote counts 5 times as much as another's 1/1 vote. It also is susceptible to gaming like happened with Roy ___ soliciting people to vote for the "multiple config. items"/sub-models issue. As it happens, that's something I was working on anyway, so it didn't make any difference to me, but it's still a potential issue. Last, and perhaps most important, it's not like we've got loads of engineers with free time that needs to be allocated. Since I tend to be 300% allocated, my votes count approximately 100x everyone else's when I'm deciding what to work on. The two big things that need to be prioritized against everything else are UML 2.x and Eclipse integration. As Bogdan pointed out, they are independent, but both of them are big chunks of work and have an impact on almost everything else. Each has a different impact on different feature sets. UML 2.x implementation is largely a cost with no functional benefit other than improve interoperability with other UML 2.x tools, at least until we start implementing UML 2.x specific features. Additionally, there are significant differences between UML 1.4 and 2.x which means that we need to decide what level of support we're going to continue to provide, if any, for UML 1.4. Will we provide ongoing support for both? One way or bidirectional conversion? etc, etc... Eclipse integration has both costs and benefits. Things like undo, context-sensitive help, automatic updates, etc are easier with Eclipse because of the provided infrastructure, but there's additional work required in other areas to get things to integrate smoothly. Expectations in the Eclipse environment are also higher, so things like multiple open projects, multiple open windows, etc are just assumed to work and this will be an additional workload to get supported. Although it keeps getting mentioned, doing an Eclipse RCP release isn't really that big a deal. It's mainly a packaging exercise and I already put together a proof-of-concept release a couple of summers ago. I've been pushing Eclipse integration for years now, saying that standalone ArgoUML is an evolutionary dead end, yet I keep wasting time on ArgoUML. That's coming to an end with the 0.26 release. I'm only going to work on Eclipse based tools. The real question is whether or not it's already too late for those tools to be based on any ArgoUML code. Brian and Bogdan have done great work on the Eclipse integration, but Ganymede already bundles support for a bunch of the UML diagrams and there's a full open source UML 2 editor, called Papyrus, being proposed for the 2009 Eclipse release. http://wiki.eclipse.org/MDT/Papyrus-Proposal http://www.papyrusuml.org/ As they begin to gain momentum, they will make it very hard for Argo based solutions to keep up. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
