Date   

Call for vote: disable sonarsource violation squid:S3725 (a.k.a Java8's poor performance on Files.Exists())

HARPER Jon
 
Edited

Hi list,

we have 46 violations of squid:S3725

https://sonarcloud.io/project/issues?id=com.powsybl%3Apowsybl-core&resolved=false&rules=squid%3AS3725

 

However, as verbally confirmed by mathbagu and geofjamg, this rule assumes that only the default filesystem (returned by Filesystems.getDefault() ) is used. For other filesystem, it is not possible to use the rule's replacement (path.toFile().exists() ).

 

Since we do use other Filesystems, I propose that we disable this rule for our project.

I vote for disabling the squid:S3725 rule

 

Cheers,
Jon



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Re: Call for vote: disable sonarsource violation squid:S3725 (a.k.a Java8's poor performance on Files.Exists())

Luis María Zamarreño García
 

On Thu, Sep 12, 2019 at 12:21 PM, HARPER Jon wrote:
I vote for disabling the squid:S3725 rule
You have my vote for disabling the rule squid:S3725
Should we use the "poll" tool from the distribution list?


Re: Call for vote: disable sonarsource violation squid:S3725 (a.k.a Java8's poor performance on Files.Exists())

BAGUE Mathieu
 

I agree to disable this rule too.

If we decide to disable it, we have to create a file that explains which rules are disabled and the reason why.


Re: Call for vote: disable sonarsource violation squid:S3725 (a.k.a Java8's poor performance on Files.Exists())

MURGEY Sebastien
 

I also vote in favor of this proposition.

Sébastien


Test

TILLOY Anne
 

Hi everybody,

 

It seems that some of you have problems to receive the emails posted in the LFE lists. I am trying to fix that problem with the support.

 

Sorry for this spam !

 

logo

Anne TILLOY
PES/DSIT/DDL
Immeuble window - 7c place du dome
92800 Paris la defense
T+33 (0)1 41 02 15 32 – P+33 (0)6 46 16 22 39

 

 



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Travis/Appveyor issues

TILLOY Anne
 

Hi Boris,

 

It seems that our builds are queued really often. The merge of a PR can take almost 4 or 5 hours. We really need to find a way to work more efficiently with github. Two ideas :

-          Less builds by PR ;

-          To pay for a better service for Travis and Appveyor.

 

I have already  raised this problem weeks ago, and you proposed to try to solve this issue on your own. What can we do ? What does the LFE propose ?

 

Thanks for your answer.

 

Anne.

 

De : JAMGOTCHIAN Geoffroy
Envoyé : mardi 5 novembre 2019 12:53
À : DDL--POWSYBL <powsybl.ddl@...>
Objet 
: Travis/Appveyor engorgé

 

Salut,

 

53 jobs en attente sur Travis, en moyenne 4 ou 5 heure avant qu'un PR ne passe. Faut vraiment qu'on fasse quelque chose, ca devient difficile de travailler correctement.

Ca va pas trop s'arranger en plus quand on va migrer nos repo Convergence.

Je vous propose qu'on cale un point en dehors des ateliers powsybl spécifiquement sur ce point pour qu'on décide de la  meilleure stratégie à adopter.

A mon avis il y a 2 grandes familles de solutions:

   - celles ou on relache des  contraintes sur les PR (moins de build par PR).

   - celles ou on upgrade le service  en payant (on paye Travis + Appveyor voir on passe sur les Github action pour n'avoir qu'un service)

   - pourquoi pas les 2.

 

Geoffroy

 



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Call for vote: committers in charge of repositories #poll

TILLOY Anne
 

Hi TSC members,

Do you agree or not with the following list of committers in charge by repository:

powsybl-core: Mathieu, Miora, Anne and Luma.
powsybl-tutorials: Anne.
powsybl-math-native: Mathieu and Geoffroy.
powsybl.github.io: all committers.
.github: Anne.
powsybl-open-loadflow: Geoffroy.
powsybl-network-store: Geoffroy and Jon.
powsybl-single-line-diagram: Geoffroy and Jon.
powsybl-dynawo: Mathieu and Luma.

Thanks for your answers.

Thank you for voting. Results will be available when the poll is closed.



Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

TILLOY Anne
 

Hi TSC members,

 

The previous poll enables to decide the people in charge for some repositories of the powsybl organization. The simple majority has be reached and the “yes” answer of the poll is approved. I am going to modify the CONTRIBUTING.md file in consequence. Before opening a new poll for the last repositories of the organization, I prefer to have a discussion with you as committers.

 

Remember that “in charge” means:

-          Best effort to review PR ;

-          Best effort to resolve issues ;

-          Building the releases with release notes and communication through LF Energy lists.

-          In case of impossibility, the person in charge has to ask the TSC through this list to find another committer to review the PR, resolve the issue or build the release.  

 

powsybl-hpc

Maybe Sylvain can review the Slurm part and Geoffroy can review the MPI part. Remember that all contributors can help doing this tasks, but only committers can merge.

Question: who should be in charge of the release ?

 

afs

I think that we have to create a separate repository for the application file system, called powsybl-afs with the modules afs, security-analysis-afs and the module afs-cassandra which is private for the moment.

Question: what do you suggest for the repository responsible ?

 

powsybl-gse

The reviews can be done by any contributor, but in general only Geoffroy merges the PR. The issues will be solved in general by Paul (https://github.com/powsybl/powsybl-gse/commits?author=pl-buiquang). For the powsybl-gse release, I think that we can propose to Paul that:

-          He prepares the PR with the two commits (prepare current release and prepare next release) ;

-          He prepares the release notes ;

-          Anne, Miora and Mathieu deal with the rest of the release publication ;

-          The powsybl-gse releases are synchronized with the powsybl-core releases.

 

Thanks a lot for your answers.

 

Anne.



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

LECLERC Sylvain
 

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 release even though there is no evolution in that repo.

It means that there is still a need for coordination between the releases of repositories (release “trains” ?).

For instance when a project uses powsybl-core and powsybl-hpc, using a new release of powsybl-core will require to have a new release of powsybl-hpc which uses that same new release of powsybl-core.

 

Best regards,

Sylvain

 

De : powsybl-tsc@... [mailto:powsybl-tsc@...] De la part de TILLOY Anne via Lists.Lfenergy.Org
Envoyé : vendredi 8 novembre 2019 13:26
À : powsybl-tsc@...
Objet : [powsybl-tsc] Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

 

Hi TSC members,

 

The previous poll enables to decide the people in charge for some repositories of the powsybl organization. The simple majority has be reached and the “yes” answer of the poll is approved. I am going to modify the CONTRIBUTING.md file in consequence. Before opening a new poll for the last repositories of the organization, I prefer to have a discussion with you as committers.

 

Remember that “in charge” means:

-          Best effort to review PR ;

-          Best effort to resolve issues ;

-          Building the releases with release notes and communication through LF Energy lists.

-          In case of impossibility, the person in charge has to ask the TSC through this list to find another committer to review the PR, resolve the issue or build the release.  

 

powsybl-hpc

Maybe Sylvain can review the Slurm part and Geoffroy can review the MPI part. Remember that all contributors can help doing this tasks, but only committers can merge.

Question: who should be in charge of the release ?

 

afs

I think that we have to create a separate repository for the application file system, called powsybl-afs with the modules afs, security-analysis-afs and the module afs-cassandra which is private for the moment.

Question: what do you suggest for the repository responsible ?

 

powsybl-gse

The reviews can be done by any contributor, but in general only Geoffroy merges the PR. The issues will be solved in general by Paul (https://github.com/powsybl/powsybl-gse/commits?author=pl-buiquang). For the powsybl-gse release, I think that we can propose to Paul that:

-          He prepares the PR with the two commits (prepare current release and prepare next release) ;

-          He prepares the release notes ;

-          Anne, Miora and Mathieu deal with the rest of the release publication ;

-          The powsybl-gse releases are synchronized with the powsybl-core releases.

 

Thanks a lot for your answers.

 

Anne.



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

VEDELAGO Miora
 

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 think there will be a need for release outside this window?


I still don't really know what to do about afs... Is there any evolution need on its repositories? Or are modifications/demands only bug fixes? Of the latter, are the demands critiqual? If they are not, we can decide to only do releases on these repo which would not be so much work i.e. only maintain them at the current state...


The bottleneck about powsybl-gse is mainly on the merging/reviews of PR. I don't really have any idea about how to handle this issue.


Miora


De : powsybl-tsc@... <powsybl-tsc@...> de la part de LECLERC Sylvain via Lists.Lfenergy.Org <sylvain.leclerc=rte-france.com@...>
Envoyé : vendredi 8 novembre 2019 13:50
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse
 

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 release even though there is no evolution in that repo.

It means that there is still a need for coordination between the releases of repositories (release “trains” ?).

For instance when a project uses powsybl-core and powsybl-hpc, using a new release of powsybl-core will require to have a new release of powsybl-hpc which uses that same new release of powsybl-core.

 

Best regards,

Sylvain

 

De : powsybl-tsc@... [mailto:powsybl-tsc@...] De la part de TILLOY Anne via Lists.Lfenergy.Org
Envoyé : vendredi 8 novembre 2019 13:26
À : powsybl-tsc@...
Objet : [powsybl-tsc] Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

 

Hi TSC members,

 

The previous poll enables to decide the people in charge for some repositories of the powsybl organization. The simple majority has be reached and the “yes” answer of the poll is approved. I am going to modify the CONTRIBUTING.md file in consequence. Before opening a new poll for the last repositories of the organization, I prefer to have a discussion with you as committers.

 

Remember that “in charge” means:

-          Best effort to review PR ;

-          Best effort to resolve issues ;

-          Building the releases with release notes and communication through LF Energy lists.

-          In case of impossibility, the person in charge has to ask the TSC through this list to find another committer to review the PR, resolve the issue or build the release.  

 

powsybl-hpc

Maybe Sylvain can review the Slurm part and Geoffroy can review the MPI part. Remember that all contributors can help doing this tasks, but only committers can merge.

Question: who should be in charge of the release ?

 

afs

I think that we have to create a separate repository for the application file system, called powsybl-afs with the modules afs, security-analysis-afs and the module afs-cassandra which is private for the moment.

Question: what do you suggest for the repository responsible ?

 

powsybl-gse

The reviews can be done by any contributor, but in general only Geoffroy merges the PR. The issues will be solved in general by Paul (https://github.com/powsybl/powsybl-gse/commits?author=pl-buiquang). For the powsybl-gse release, I think that we can propose to Paul that:

-          He prepares the PR with the two commits (prepare current release and prepare next release) ;

-          He prepares the release notes ;

-          Anne, Miora and Mathieu deal with the rest of the release publication ;

-          The powsybl-gse releases are synchronized with the powsybl-core releases.

 

Thanks a lot for your answers.

 

Anne.



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

MURGEY Sebastien
 

Hi,

I have no remarks, and I agree with this proposition.

Regards,
Sébastien MURGEY


Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

HARPER Jon
 

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
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse
 
Hi,

I have no remarks, and I agree with this proposition.

Regards,
Sébastien MURGEY


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

JAMGOTCHIAN Geoffroy
 

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 14:49
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse
 

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
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse
 
Hi,

I have no remarks, and I agree with this proposition.

Regards,
Sébastien MURGEY


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


IIDM Versionning - questions

VEDELAGO Miora
 

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, we wanted to be able to read/validate older versions but only write in the latest (i.e. current) version. However, this will bring a lot of restrictions in processing XIIDM files. Should we allow to serialize in older versions?


If the answer is yes, here are our proposition:

  • Handling of XIIDM breaking changes
During export, the responsability to check compatibility between the version the user wants to write in and the network itself (i.e. to check if every component of the network can be serialized in the given version) is on the serializers of the network components.
    • New equipments:
If a new equipment is added in version N, the user will only be able to serialize it in version N and newer (N+1, N+2...). If they try to serialize a network containing this equipment in older versions, an exception will be thrown by the equipment's serializer.
    • New attributes
      • optional:
If a new optional attribute is added to an equipment in version N, this equipment will be serializable in older versions (N-1, N-2...) if and only if this attribute has its default value. If its value is not the default value, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.
      • required:
If a new required attribute is added to an equipment in version N, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.

  • Handling of extensions versionning:
Some extensions are dependent on XIIDM (e.g. CurrentLimitsPerSeason depends on CurrentLimits modelisation in XIIDM). Hence, extensions should be versionned as well.

Some specific examples:
  • Changing of attributes name for steps: the attributes names will depend on the version the file is imported/exported
  • Addition of new attributes for shunt regulation
    • During import of 1.0 XIIDM files containing shunts, shunts will be considered as not regulating
    • During export as an 1.0 XIIDM file of a network, if the network only contains not-regulating shunts, it will be exported with the old modeling, else (if the network contains regulating shunts), it will throw an exception
  • New modeling to discriminate linear and non-linear shunts
    • During import of 1.0 XIIDM files containing shunts, shunts will be considered as linear
    • During export as an 1.0 XIIDM file of a network, if the network only contains linear shunts, it will be exported with the old modeling, else (if the network contains non linear shunts), it will throw an exception
  • Modeling changes for current limits: it will be considered as an extension
    • During import of 1.0 XIIDM file containing current limits, we will read them and import them as the new extension of the network
    • During export as an 1.0 XIIDM file, current limits will be serialized as they were in XIIDM 1.0 and/or (?) as an CurrentLimits extensions compatible with XIIDM 1.0 (todo)
  • Introduction of apparent power limits
    • If we model them as extensions, there will be no major compatibility issues
    • Else, it will mean creating a new field which cannot be serialized as XIIDM 1.0 and will throw an exception if it is attempted
Is it clear for you? Do you think writing in older versions should be an implemented feature? If you do, do you agree with our propositions? Have you something to add to them? If you don't, how should we handle old versions files in your opinion? Don't hesitate to describe specific use cases to press your point.


Miora RALAMBOTIANA
CHARGE DE PROJETS MAINTENANCE EXPLOITATION SI
PES - Direction Système d'information et Télécom - Département Développement Logiciel - Système électrique
miora.ralambotiana@...
rte-france.com 


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


Re: IIDM Versionning - questions

MURGEY Sebastien
 

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 this feature.

In case we decide to do that development, I agree with the proposition.

Sébastien


Re: IIDM Versionning - questions

BAGUE Mathieu
 

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 (or XML converter implementation) in that case? You have to be able to update each component independently but with a strong bond to the IIDM format, you cannot and it will be necessary to update all components in the same time. I think the problem also occurs if the networks are stored in a shared database.

Best,
Mathieu


Re: IIDM Versionning - questions

MURGEY Sebastien
 

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 months we have to align ourselves on our releases because of IIDM XML export breaking changes, this issue will be far more important than if it is only once a year...


Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

BAGUE Mathieu
 

Hi,

A summary, just to be sure I understand well the proposal:

powsybl-hpc
  • Review: Geoffroy (MPI), Sylvain (Slurm)
  • Release: Sylvain
powsybl-afs
  • Review: Paul, Geoffroy
  • Release: Paul (release notes), Mathieu/Miora (upload)
powsybl-gse
  • Review: Paul, Geoffroy
  • Release: Paul (release notes), Mathieu/Miora (upload)

About powsybl-afs and powsybl-gse repositories, the uploaders will be changed when a (new) commiter will uses these repositories.

Best,
Mathieu


Re: IIDM Versionning - questions

LECLERC Sylvain
 

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 use new features of powsybl (and hence a new IIDM format), it will have to wait for all client applications to have migrated to that version of powsybl and deployed a new version.

This may have strong impacts on deployment schedules in our IT systems, and does not seem acceptable.

 

2)      About the proposal, I am OK with most of it, but I would propose to relax the requirements on new attributes:

if a new attribute is not required by the version 1, I think in most cases it should not throw when serializing to that version, even if the attribute is required in version 2.

Maybe this should be decided on a case-by-case basis : for some new attributes, the network will still make sense without them, maybe with some adaptation (like transferring it to an older attributes), while for others it will not.

 

Best regards,

Sylvain

 

 

De : powsybl-tsc@... [mailto:powsybl-tsc@...] De la part de MURGEY Sebastien via Lists.Lfenergy.Org
Envoyé : mercredi 20 novembre 2019 09:11
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] IIDM Versionning - questions

 

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 months we have to align ourselves on our releases because of IIDM XML export breaking changes, this issue will be far more important than if it is only once a year...



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."


New repositories in powsybl organization #poll

VEDELAGO Miora
 

Hi TSC members,

This is a reminder that to ensure transparency for everyone, anyone creating a new repository in the powsybl organization should:
  • submit a poll here (on powsybl-tsc) before creating it to make certain everyone in the TSC is aware and consents to the creation of the repository
  • update the MAINTAINERS file in the .github repository
  • send a message on powsybl-announce indicating the creation of the repository, its name and a small description of which purpose it serves

If you agree with this steps and to apply them in this situation, please vote Yes to this poll. If you don't, vote No and develop your point of view as answer.

Thank you and have a good day,
Miora Ralambotiana

Results

See Who Responded

1 - 20 of 158