agree with about no mention to SA. It made me think other
thing, about the .sa resource. It must be not exist.
is a fundamental question that needs one precise response
me and for CEA members, ESF is not SA vision. ESF is a mixed
of All4Tec and CEA expertise. ESF needs to be open for
others too, if possible. But now, for pragmatism reasons,
for me, ESF is temporally under baseline of SA. In
parallel, the new basis should be developed for ESF.
other fundamental question, if you and All4Tec agree with
the previously response, is:
example, the “…esf.core.metamodel » (from SA) current is not
coherent with “…esf.core.profile” (ESF Core Profile, in
working. It is the basis for the future of ESF).
this reason, I proposed the repositories dedicated to the
code from SA. But, I agree ESF-SA is not good.
must think how coexist the two development in the same
repository or not. Maybe the branches make the job.
I agree that we should separate our repositories by
'feature' or domain, but I don't think that separate them
for Safety Architect is the right decision. ESF is a product
by itself, and we should not mention SA in it. We can
however separate the 'core' provided by SA from the 'core'
provided by Papyrus, the thing is that the repo should be
named by their function and not their origin. For example :
- ESF-MODELER :
stores the core and common code for the graphical
editors, e.g. ESF Core profile
ESF-DOCUMENTS: stock the specifications, models, papers,
ESF-INFRA : stores the core and common code from SA
ESF-CONNECTOR: stores the “parsers” from SA
ESF-TOOLS: stores the analyses tools from SA
Even if the name Modeler is may not be the best one... I
think that is enough to allow us to evolve and add new
analysis or representation.
Le 10/03/2015 10:38, MUNOZ JULHO Yupanqui
a écrit :
In the last
conversation we defined four repository:
After the new
reflections about the ESF’s present (SA open source) and
ESF’s future (new conception of the safety analyses and
open to the new and external contributions + SA) I think
that the SA codes should be in the separated repository:
- ESF-INFRA: stores the core and common code, e.g. ESF
- ESF-DOCUMENTS: stock
the specifications, models, papers, demos, etc.
: stores the core and common code from
stores the “parsers” from
stores the analyses tools from
What is your opinion?
We can debate about
this Thursday in the meeting.
esf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit