Hi Nico,
On Jul 24, 2012, at 11:03 AM, Nicolas Anquetil wrote:
some comments on all I read in this thread:
- the idea of unified repository is very nice for research. It is important if we want to
be able to share results, and reproduce experiments.
Could it have some interest for industry projects?
For example, it could be usefull as a comparison base for a company to understand how
good or bad its own software is compared to some other (presumably open source) projects
...
- keeping source code (and much more) is important because you never know what people
would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
- metadata verveinej version.
For now, what I do is I keep a copy of verveinej along with the project. It is not big
(<20Mo.)
Anyway, it does not change that much, just keeping the date of the download should be
enough for now to track versions.
Tis is what I do for now.
- server generated MSEs.
It can be a nice thing for small projects, but from my experience, generating MSEs is not
trivial.
Think about it like compiling a project (converting from one language to another).
It requires setting up the path correctly, pointing to the right libraries, may be
generating some source code, ...
Not something you can automate.
And for industry, it would not work. A company would be very cautious about sending its
source code to some unknown server.
- memory
I commented with Jannik that a 2Gb. image for a 650Mo. MSE file looks like a huge
difference to me.
This is an issue because the VM is constrained in memory whereas the size of software
systems does not seem to be :-)
How can we deal with REAL BIG systems? 10 MLOCs for example ?
That is a problem. We will overpass this problem by increasing the memory of the VM, but
it does not solve the problem.
Maybe a database...
- verveineJ vs. inFamix
I never really used inFamix, so I cannot tell.
Doru seems to be the one that knows better both projects (and all of Moose as usual :-)
).
May be he has some idea on the pros/cons of each tool ?
- licence: We are trying to startup a business around moose. We think this is something
that could be profitable to the entire community. On the other hand, this is not something
easy to do and we need to take care not to shoot ourselves in the foot. It is like raising
a baby, it is better to be a bit over protective and correct things afterwards than to be
too much confident and risking a serious accident ...
So the license is closed for now and we give explicit permission to friends to use it.
And we did not yet formalize it at the moment simply because it does not rely only on us,
it requires legal knowledge that we don't have, and above all there are a lot of other
things to do that are more urgent.
As for rewriting a new (open) one. Yes you could. But why loosing time with this? The
solutions exist for now that you can use and work with. If in the future the situation is
really unbearable, then you can think of investing time in correcting it.
(and as mentioned, don't underestimate the amount of work it represents. Sure, any of
us can do it, but it means months of effort, do you really have that much free time to
spend ?)
I do not really want to do this, but if Moose become close, what about the community ?
The reason why we move from Visual Work to Pharo is because Pharo is open-source and we
control it.
Jannik
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval