Hello Thomas!
My comments inline!
2008/6/6, Thomas N. <[EMAIL PROTECTED]>:
>
> Hi,
>
> the urgent need for the code restructurings and other work under the hood
> that Tom and Bob pointed out is something that I absolute agree with. My
> frustration came from the fact that this takes so much time that not much
> beyond this is achieved. The basic problem seems to be that we have too few
> resources for all the work that needs to be done. So there happens to be
> some selection, for *example* (% of achievement):
> 1. restructurings 75%
> 2. library+repository upgrades 9%
> 3. API maintainance 9%
> 4. bug fixes 5%
> 5. new features 2%
> From a users point of view, this progress over time is not much better
> than just doing nothing, so the natural conclusion is: "hey, this project is
> dead". All this is not a solution, nor is there any accusation, but just
> expresses what I feel about this project. (BTW: I must admit that the
> subject of this thread is kind of wrong, maybe it was too provoking.)
Alas, I don't have a solution to this. I am very glad that you all work as
hard as you do to improve things. It is an extreemely slow and painful
process but I don't see any other way to improve the code.
The simple solution is that we all need become more numerous and to work
harder to get through the restructuring and bug fixing part.
Maybe we should overcome this image problem by choosing one of the big
> eye-catching issues, like the missing Undo or the UML2 issue, and come up
> with a quick solution even if it's not the optimal way from a technical
> view. Example: use a UML2 repository with our UML1.4 API (I thought the
> Model API was designed to allow a quick repository change?) while not (yet)
> supporting ANY UML2 feature and simply declare ArgoUML as an UML2 tool.
> (Technically nonsense, but will get some attention, at least ArgoUML won't
> be thrown out in numerous tool evaluations.) This is just an example.
Please go ahead! Add that eye-catching feature or features. We need them!
The reason why this is not happening is, because we are uncoordinated and
> just technically driven. There is no balance between technical needs and
> "marketing" needs. There is no written mission statement for the next
> release(s). There is no commonly accepted decision, everybody works on what
> he wants. So one problem is a governance problem.
Well, yes, you are probably right. We are not a team.
Do you have a suggestion on how to solve this?
Another problem I see is the knowledge base of the project. Active living
> are only the dev mailing list and issuezilla. Good, but not sufficient for
> quickly see what's our overall direction, what the currently hot topics are
> and which is their current state, not structured and not easy editable. I'm
> still VERY MUCH for a Wiki solution here. (BTW it's very hard in issuezilla
> to find the key issues among the thousands of minor or outdated issues, but
> this could be fixed, hopefully.)
Two comments...
Why is it that the Cookbook and the web site dev pages are not considered an
active knowledge base of the project? Can't you update them as you go along?
The big Tigris upgrade, that we have been waiting for for several
months, seems to be just a couple of weeks away now, if nothing unforeseen
happens. Rumor has it, it contains a wiki and I have previously announced
that I plan to move the Cookbook into it and I hope we can take it from
there.
And some other problem is (this directly relates to my previous mail): we
> developers have a hard time contributing to ArgoUML, because one immediately
> gets into the deepest code reorganisation problems when joining the project.
> Let it be enhancements of the graphical appearance of diagrams or CG/RE or
> whatever. You want to help enhance ArgoUML, and suddenly you're lost in many
> deep tasks you originally were not interested in for a looong time. Might be
> a reason why we are so few developers. (Again, I have no solution but wanted
> to express my feelings.) Would be nice if we had some abstracion layers so
> that there really could be different types of developers (which leads me to
> the subject of the thread).
Yes, you are right. We need this!
What do you want me to say?
Please go ahead and fix this!
or
Please, if someone has done reorganization of a part of the code and you
want to use that code but you are having problems and don't really
understand the idea behind it, don't annoy them by objecting when they are
setting you straight. Just accept the new and improved solution! (And once
you have understood, improve the javadoc comments and Cookbook for that area
since it was obvious that it wasn't good enough in the first place or you
would have understood.)
Introducing modules and subsystems was a very good and visionary step,
> thanks Linus and others!
Thanks!
[...]
/Linus
