I agree that Tom's contribution to the project is huge. I think it is a lot
more than the 50%. We could do with a few more developers with his
enthusiasm and efficiency.
/Linus
2008/9/11 Christian López Espínola <[EMAIL PROTECTED]>
> 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>
>
