Hello all!
To get the more frequent releases going and to solicit commitments from
developers and make them into plans, we need to spend more time on this.
Since I will not be able to spend considerably more time then I currently
do, my question is who we want to assume the Release Responsible for all
Releases role and make this happen?
Is this something for you Christian?
/Linus
2008/9/10 Tom Morris <[EMAIL PROTECTED]>
> 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]
>
>
