Hi Tom, I'm a little bit disappointed that this mail hasn't won our attention, or at least nobody followed up on the conversation.
On Wed, Sep 10, 2008 at 12:38 AM, Tom Morris <[EMAIL PROTECTED]> wrote: > 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. <snip> > 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. I agree with this. For work that can take a lot of time, or if someone cannot assure that his commitment (because of time restrictions or anything else) to ArgoUML, we could use branches, so trunk is always stable, or at least very close to be stable. > 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. That's true, and IMHO is what we have been doing. BTW, users count, and we should take care of them. I don't need to look at the votes (truly, I think that I have not done that never) for knowing that Undo/Redo and Copy/Paste are some of the most wanted features. > 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. I agree, but we have to be careful. Those tasks are (or seem to be) very hard (talking about time), so we have to do a good plan about who could/will be involved, and how many time he is able of working on it. Once we know about it, we can plan if it should be developed on trunk or in branches. > 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... I've thought on this before, but I haven't found the right answer. Should we support both profiles? Or should we update our users to 2.x automagically? I'm sure that we can achieve 1.4->2.x, but not sure about the other way. <snip> > 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/ I don't think that one alone person shouldn't influence all the work of the ArgoUML team. In other case, I'd say 'Thanks for the fish, goodbye'. But Tom is, IMHO, one of the main sources of man-power in our team. Everyone of us know his commitment, and how many time he has spent with us. Furthermore, you can look at how many issues have been fixed between the first 0.26 alpha and the last beta. I haven't done it myself, but I'm sure that +50% have been fixed by him. And more important yet, what Tom says is something that I have heard often before. Researchers said me (years ago!) 'Everybody in the Research Field works with Eclipse based tools, don't waste your time with Argo'. I ignored them, but it is very difficult to close your ears for years. We have to invest on Eclipse, or Argo will die (with a pretty corpse). An user idled today at IRC asking a question, and Alex (argouml-python) and me chit-chatted a little bit with him. One of the things he said, and he allowed me to quote: [19:32] <melter> there hasn't been a release in over a year and a half [19:33] <__alex> currently there is one going on, but it's not a stable one [19:34] <penyaskito> melter: we want to make shorter the SDLC of ArgoUML [19:34] <penyaskito> melter: I want to see 0.26 out before november, and I would like to see 0.28 in about six months [19:35] <melter> penyaskito: even having bug fix releases monthly would at least show the project has some life [19:35] <melter> like 0.26.1, 0.26.2, even just for a spelling fix I think that we could do that. What about working on Eclipse & UML & new features in trunk, and having a 0.26 branch where we can work on bugfixes? If we're meticulous with creating Issues and good SVN commits logs, it's not hard to know what is a bugfix and what is a new feature, and patching the branch accordingly. I tend to review all the mails of argouml-commits, I'm sure that most of you do too. Even more, we can plan to do 0.28 with SoC projects, guiding 0.28 development in a branch, so we can work in the hard task of EUML and Eclipse integration in Trunk, and do a 0.28 release with those improvements and maybe others + bugfixes of 0.26.x, without stopping Tom or others of working in Eclipse integration or EUML. If trunk is ready soon, Eclipse integration is in 0.28. If not, we can release a 0.28 without it, and work on it for 0.30 (maybe renaming 1.0?). About releasing, I'm sure that it should be easy to adapt the scripts for this. Instead of using trunk, we can tag from a branch without any problem. Sorry for the long mail, but I expect that you've read it until the end, and answer my previous concrete proposals. -- Cheers, Christian López Espínola <penyaskito>
