Hi all, Geoffroy and I started a discussion about the content of powsybl-core and the opportunity to well separate this repository because: - it is relatively big enough to be splitted - modules are

Hi, We have designed additional profiles management in a very modular way (IIDM extensions + CGMES post processor plugin). For th powsybl-cgmes-gl its contains not only the web service but also a

Hi, Just a question about CGMES GL: are we sure we want to put the code of each profile (GL, DL, DY...) in different repositories? Or should we create a more generic CGMES repository (or put

I created a PR in the documentation, to add a technical documentation section, a micro-services architecture diagram (and repo mapping) and a short description of each of the

I think we can also create a page on the website to describe, for each repository, which features it offers. With the multiplication of the repositories, we need to have somewhere a clear picture of

This is mainly to prevent TSC members (people responsible of the technical direction of powsybl) ignoring what the point is of some repositories - a situation that can happen when repositories are

And also we should vote for any maven module, class, package and variable naming, right?

Hi all, 1) Unfortunately I think the use case is important. If we don’t have this feature, if one application provides IIDM data to other applications and if that first application wants to

Hi, A summary, just to be sure I understand well the proposal: powsybl-hpc Review: Geoffroy (MPI), Sylvain (Slurm) Release: Sylvainpowsybl-afs Review: Paul, Geoffroy Release: Paul (release notes),

I think there are organisational ways to solve this type of issues. However, I understand the use case shared. It also largely depends on the rythm of breaking changes creation in IIDM. If every two

Hi Sebastien, all, When Miora and I thought to the backward compatibility, we considered an architecture with 3 systems that exchange networks, but with a cyclic dependency. How do you update IIDM API

Hi all, On my side, I do not think the benefits of being able to do that kind of backward conversion are worth the complexity of the associated development. I do not have any critical use case for

Hi all, As you may know, we are currently working on the versionning of XIIDM. In this context, the main question we have is: do we need to handle the serialization of different versions? At first,

I also agree with the proposition. Geoffroy De : powsybl-tsc@... <powsybl-tsc@...> de la part de HARPER Jon via Lists.Lfenergy.Org <jon.harper=rte-france.com@...> Envoyé : lundi 18 novembre 2019

I agree De : powsybl-tsc@... <powsybl-tsc@...> de la part de MURGEY Sebastien via Lists.Lfenergy.Org <sebastien.murgey=rte-france.com@...> Envoyé : lundi 18 novembre 2019 14:41 À :

Hi, I have no remarks, and I agree with this proposition. Regards, Sébastien MURGEY

Hi all, @Sylvain: yes, there is a need for coordination for releases. I think a good solution would be to have a regular release for all repos (once every six weeks? or something like that?). Do you

Hi Anne, all, It would be OK for me to be in charge of powsybl-hpc releases. It may be obvious, but please note that for “second level” repos, releases of “core” repos may require a