Hi Thomas

I find your views rather odd and rather worrying.

> the recent discussions about the import interface revealed a conflict between 
> two goals of open source software development, that split the developers in 
> two types:
> - enhance the codebase to make it maintainable, extendable and 
> state-of-the-art
> - add new domain specific functionality that users need
Why do you think that someone would be so motivated to only be
interested in working on the framework and maintaining other peoples
code?

I imagine all developers would prefer to spend their time adding new
features in a structured way to a stable base. Unfortunately though
that is not what we have and there is a lot of work to do there that I
hope we'll all contribute towards.

If the work done so far had not happened then we'd still have one
horrible lump of spaghetti code still at UML1.3 and all the features
thrown into that lump would quite simply not be used now. The
spaghetti is unravelling gradually, thought needs to be put in by
everybody so as not to move us backwards again.

> About the second goal first..... they are also willing to introduce dirty 
> hacks for the sake of their desired functionality.
If you introduce such a hack then I'd consider you responsible
resolving it as soon as possible rather than considering that the duty
of someone else who likely has something far more interesting to do
for themselves.

> ....had to postpone my feature ideas for YEARS for several reasons....
I'd have to agree with Tom here. It seems you chose to delay
implementation. You could have concentrated on defining an interface
for the SD reverse engineering to talk to that worked on the old
implementation before Jaaps rework. All implementation following that,
including Jaaps and Christians would then have been compatible as
would any future implementation using eclipse technologies. It seems
that the definition of that interface is now considered to be
something I should get involved in even though I've had no involvement
in RE and is something that is likely to delay release of the new SD
implementation. The desire to do something quickly in the past is
slowing things up now.

> ......but now I see this is a neverending story....
It has been a never ending story while ArgoUML was such a big lump of
circular references where every public class/method was considered the
public API. Almost any change could break a module. The plan to go to
RCP I hope will gradually help to resolve this as will our own
stricter interfaces. The way to shorten the story is to help with
that.

Bob.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to