Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Status of RT Model Migration (Import) in 1.0
Please forget the JDT analogy - I was misinformed and they’re distributing the Java 9 support capability through the Marketplace…


Regards,

Charles Rivet
Senior Product Manager
charles@xxxxxxxxxxxxx

On 2017-06-28, at 12:57 , charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:

I reviewed the incubation rules and they are much less stringent than I originally thought… It is really about the project team learning the Eclipse process, IP certainty, community building, and a (rather vaguely defined) quality level than anything else.

Yes, none of the modules can be tagged as “incubation,” but I could not find anything that would prevent use from having “beta” level components for which we would want feedback, similar to JDT’s Java 9 “beta” support until Java 9 is released on September 2nd...

So I would say that all of the Papyrus-RT and Papyrus modules mentioned below should be part of the 1.0 release and that none of those should be marked as “incubation”! The release notes should then include mentions those modules' level of readiness for industrial usage.

If this is an issue, I am sure it will be brought up in the graduation review! (or I can bring it up with the EMO's legal folks in advance.)


On 2017-06-28, at 08:25 , Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Thanks, Peter.

That bugzilla reference is helpful.  Looking at the bundles that show “(Incubation)” in their names, I see that the Xtumlrt bundles all purport to be in incubation.  But codegen is based on this as an intermediate representation, so this suggests that Codegen also should be in incubation still.

Cheers,

Christian

On Jun 28, 2017, 08:20 -0400, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
Hi,

The discussion about leaving the textual feature in incubation was held in bug 513384, in which also this about leaving the RSARTE migration feature in incubation.

Exactly what it comprises I leave to Ernesto to explain which I assume is the one that knows that best.

/Peter Cigéhn

On 28 June 2017 at 14:04, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi,

What exactly comprises the textual feature?  Is it just the org.eclipse.papyrusrt.xtumlrt.xtext.feature?  Who has decided that it is still in incubation?  Is that just because it isn’t in the MVP?

Cheers,

Christian

On Jun 28, 2017, 07:52 -0400, Camille Letavernier <cletavernier@eclipsesource.com>, wrote:
Hi,

The migration tool is part of the Tooling update site, so it is available on Hudson:


I don't know the publishing policy for Papyrus-RT update sites, so I don't know if this is/will be available somewhere on the downloads server

Regarding the whole incubation/versionning policy, I'm not sure if they are guidelines (So you may include "incubating" components in your project, even if the project is graduating, although they should be clearly identified as such), or if they are strict rules (In which case Papyrus Extra plug-ins are probably not an example to be followed)

Cheers,
Camille

On Wed, Jun 28, 2017 at 1:30 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Peter,

If the Migration component is not graduating, then it cannot be included in a release that is intending to graduate.  And the release deliverables (as I understand them to be) are the p2 Repository and the RCP package, so these cannot also include incubating content.  It worries me that the tagged git source repository also is a release deliverable (as in any Eclipse project), which does include this incubating content.

For the tester setup, yes I think we should be able to add an optional Oomph-project that can be imported to bring in a component like Migration.  And that would be from the Tooling job’s artifacts archive on Hudson or, better, from some dedicated p2 repository that doesn’t exist yet on the download server.  So, the job of re-integrating the Migration component isn’t yet finished, but that Gerrit change prepared the way and unblocked other work for finalizing the release (such as version numbering).

Cheers,

Christian

On Jun 28, 2017, 07:23 -0400, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
Hi,

I am not sure that I have followed along in all the details in what has been decided regarding how the RSARTE migration/import shall be handled.

But I would have at least expected to be able to test the RSARTE migration/import, even though it shall not be part of the 1.0 release (and that that the RSARTE migration feature itself will be left in version 0.10). But after the merge of the Gerrit change, I can still not find the 0.10 version of the RSARTE migration feature anywhere.

Don't we even plan to make the RSARTE migration feature available anywhere, not even in p2 repo available only on Hudson. I guess it makes perfect sense to not include it in the release p2 repo.

What I would have expected at least was that the RSARTE migration feature was available in some p2 repo, and that we re-enable it in the Oomph tester setup file, so that any advanced user (including myself) at least are able to play around with what we have so far, even though it is formally not included in the 1.0 release, i.e. it is not included in the RCP and the Oomph end-user setup.

Or do we not even plan to make it available for advanced users in any p2 repo, only have it available as source code in the Git repo? Isn't that taking this a bit too far and making this a bit too complicated for anyone that wants to try out the import?

If I compare with the support the textual notation (which is not part of the 1.0 MVP either), it is still available in the p2 repo for anyone who wants to test it out. I guess we should make the same for the RSARTE migration feature.

/Peter Cigéhn

On 27 June 2017 at 15:43, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm> wrote:
Hi all,

The RSA Interoperability feature has been released in Papyrus. i've updated my contribution(s) [1], which is now ready for final review/integration


Cheers,
Camille

On Fri, Jun 23, 2017 at 12:57 AM, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
First, import of RSA models is not part of the MVP for v1.0. Given the discussion below, I would think that is should not be part go the 1.0 release.

Second, it appears that this may be more than would be acceptable in a 1.0.1 release, so it should be considered for the 1.1 release.

Third, the model import will not be a “project” in the Eclipse sense. It will be a component in an upcoming Papyrus-RT release.

That being said, the discussion below is warranted, but it cannot supersede the current product plan. We need, must, concentrate on aspects that have been identified for the release.

 
Regards,

Charles Rivet
Senior Product Manager, Papyrus-RT product leader

On 2017-06-22, at 14:17 , Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Yes, Eclipse doesn’t require a correlation between version numbers and incubation status, especially for projects that had already produced releases before moving to Eclipse and incubating there.

I am inclined to agree with Peter that import is not ready for graduation and if it is to be an incubation component, then that should be called out in the Graduation Review materials to give the community, Modeling Project, and EMO an opportunity for comment.  So, yeah, let’s keep those patches on ice.

Cheers,

Christian

On Jun 22, 2017, 03:49 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm>, wrote:
Hi,

I don't have any specific opinion on the version numbers and incubation status. We've been living with Incubating/Non incubating components in Papyrus for some time, so we can probably do the same in Papyrus-RT. If it's just a matter of keeping v0.9.0 instead of 1.0.0, and (Incubation) in the feature/plugins name, then that's fine. I think the migration feature is already a distinct one (Same update site, but not directly part of the tooling), so this doesn't seem to imply any additional work (e.g. restructuring)

Regarding this question:

> In any case, probably this means that we can proceed with your gerrit patches.  Are we all agreed on that?

We still rely on a temporary update site hosted on Papyrus Hudson, so I don't think it's a good idea to merge the patches yet. I don't know when the actual release of Papyrus-RT is planed, but I'd prefer to be sure that the required Papyrus bits are available first, rather than push now and revert later :)

Camille

On Wed, Jun 21, 2017 at 4:02 PM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Well, considering the status of the RSARTE import tool (disregarding this discussion about the status of what it depends on), I would not like to see it leave incubation. I don't think that the import tools is mature enough to let it leave incubation.

To be honest, I am not sure that I think that the RSA import tool should leave incubation either, and from my earlier understanding, it would still be in incubation. I guess the version numbering just follows along the old version number from when it was part of the extras components of Papyrus for which a lot of them left incubation too early. This as I have understood is what they have tried to correct with moving out stuff into separate repos, e.g. the incubation repo for stuff that really should be incubation. I also thought that the interoperability repo would be in incubation. But I guess this is something that really needs to be checked with the Papyrus project if it really have left incubation already.

Anyway, the discussion we have had so far has been to leave RSARTE migration in incubation. See for example the discussion in bug 513384 where we left the wording "Incubation" for the RSARTE migration feature.

But I am probably not the right one to make this call whether it should graduating or stay in incubation. Personally I think we will send the completely wrong message to the community if we stated that it was graduating, because it is not mature enough and people would just get the wrong expectations if we did graduate it prematurely.

/Peter Cigéhn

On 21 June 2017 at 15:52, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Camille,

Thanks for the clarification.  Indeed, I thought for some reason that the whole Papyrus Interoperability project was in incubation.  There may have been some talk of releasing the Papyrus-RT RSA-RTE Migration component as incubation only for this release, I’m not certain now.  Perhaps Charles or Simon can comment on that.

In any case, probably this means that we can proceed with your gerrit patches.  Are we all agreed on that?

Cheers,

Christian

On Jun 21, 2017, 09:30 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm>, wrote:
Hi Christian,

I'm not sure this is an issue of "Incubation vs non-incubation", as Papyrus/Interoperability is not "incubating". It's just "not released yet" (i.e. no stable update site, and I'm not sure about release review/ip log, since this should also be done at the project level)

The plug-ins we are using for the Model Migration are:

- Papyrus Interop: "RSA to Papyrus Import tool" (v1.4.0, not released)
- Papyrus: "Papyrus M2M QvTo Common Plugin" (v1.0.0, released)
- Papyrus: "Papyrus UML M2M QvTo Common Blackboxes Plugin" (v1.0.0, released)
- PapyrusRT: "Papyrus-RT UML-RT Profile" (v0.9.0, incubating)

So unless I missed one, none of them is actually incubating (Except the PapyrusRT profile, but it would graduate at the same time as the Model Import tool - or even before that)

Most of these plug-ins are part of the Papyrus Main plug-ins, so there's only one plug-in missing, which needs to be officially released on the Papyrus side

(Or is there also a debate about whether the Papyrus RT migration tool itself should be incubating or graduating?)

Cheers,
Camille

On Wed, Jun 21, 2017 at 3:00 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Nice work, Camille.  It looks like all of the bits are in place to restore the migration feature.

However, we still need to come to a decision on how to proceed.  If we intend to graduate with a 1.0 release, then AFAIU it’s an all-or-nothing deal.  No part of that release may be in incubation.  So, if the migration component is to release as a 0.10 then it will have to be a separate build with a separate deployment and installation from a separate p2 repository.  (note that version numbering doesn’t have to correlate to incubation status, but it is helpful to users)

Otherwise, if we want to graduate the migration feature too, then of course its dependencies in Papyrus must be released as non-incubation, too.

The EMO’s Wiki page about incubation talks exclusively in terms of Project.  The migration component is not a Project; Papyrus-RT is.  Has anyone discussed the details of our plan with Wayne/EMO?  Maybe it only matters to conform to the Incubation guidelines if we wanted to use the parallel IP process, which we don’t?

Cheers,

Christian

On Jun 21, 2017, 07:36 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm>, wrote:
Thanks, Christian!

It took me some time to figure out how the build was configured (I initially thought the migration was part of the tooling, but that's not exactly true :) ), so your rebase probably cleans up a few things :)

This commit was part of a commits chain, so I've rebased the other 3 commits on top of it. The Gerrit-Migration build should be green after that

Camille

On Tue, Jun 20, 2017 at 5:02 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Camille,

Thanks for working on this!  As I merged today some changes in the TPs that conflicted with yours, I took the liberty of rebasing your change 99631 to re-generate the TPs and I’ve re-enabled the Migration component Gerrit build to verify the TP at least.

Cheers,

Christian

On Jun 20, 2017, 05:14 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm>, wrote:
Hi,

The model migration for Papyrus-RT is mostly fixed. It will depend on a release of the "Papyrus Interoperability" component(s) for Oxygen. The releng part is also ready I think, although the Gerrit job for migration is disabled, so I can't test it online (Currently, the releng relies on the hudson/nightly update site from Papyrus Interop).

Camille

On Mon, Jun 19, 2017 at 5:12 PM, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm> wrote:
Hi,

I've opened Bug 518469 to investigate the migration status. If the migration doesn't need any fix on the Papyrus side, then we could perhaps reuse the Neon bits (Although this wouldn't solve the "incubation" issue, but at least the neon plug-ins are 'released'). If some work is required on the Papyrus side, then we'll see what it would take to release something

Cheers,
Camille

On Mon, Jun 19, 2017 at 5:02 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi,

As far as I can tell, there isn’t going to be an Oxygen release of the Papyrus Interoperability component that delivers the RSA Migration infrastructure.  I don’t see any repository on the download server that would provide this, and the nightly build (currently disabled) of the Papyrus-RT migration component gets the Papyrus bits directly from the Papyrus Interoperability Hudson build job.

If I’m wrong, please somebody tell me where the Papyrus Interoperability release repository will be.  Otherwise, there’s no question of releasing a Papyrus-RT migration feature, even as incubation, because it cannot use unreleased software.

Cheers,

Christian

On Jun 19, 2017, 10:54 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm>, wrote:
Hi,

I'm not sure exactly what the intention is, and I've not looked into the details of the failure. My naive assumption at this point is that the transformation "mostly works" (From RSA to Papyrus-RT Neon), except for the references to the Viewpoint prototypes (Which, I believe, break very early and very badly, probably preventing the rest of the transformation from even starting)

So we could simply replace the broken references, then let run the RSA to Papyrus/RT transformation as-is (Targetting Mars or Neon format), then rely on existing reconcilers to transform the individual diagrams from Mars/Neon to Oxygen (As we did for the Mars -> Neon transition)

Since I'm still not too sure about the changes which occurred this year, there could be more issues. But fixing the broken viewpoint references is a mandatory first step anyway (I don't know if it also requires fixing in Papyrus, if there are viewpoint-based diagrams handled by the Papyrus transformation)

Camille

On Mon, Jun 19, 2017 at 4:31 PM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Yes, there are some work, not only related to releng, related to the RSARTE model migration (import). See some discussion about it in bug 517688 where it was decided to write a new bug for the work regarding restoring the tests for RSARTE model migration (import). But this has not been done so far (I had hoped that Rémi or Camille could write such a bug since I did not really know how to formulate it). I guess that bug also should/could cover the releng aspects...

Personally I think that we should try to provide what we have related to the RSARTE model migration (import) with a little effort we can to get it working again. It should still be in incubation (since it depends on the RSA model migration (import) tool which from what I have understood also still is in incubation). So we need to keep the RSARTE model migration (import) "separate" from the stuff in Papyrus-RT 1.0 that will leave incubation.

/Peter Cigéhn

On 19 June 2017 at 16:15, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Team,

In looking through the Target Platform definitions for the Papyrus-RT build, I see still that the Papyrus RSA Migration feature dependency is commented out in various places.  This was done originally because when we moved onto Oxygen, there was an interval in which viable builds of this component were not available from Papyrus.

But, also, judging from activity on migration-related bugs, it seems that RSA-RTE model import was back-burnered for the 1.0 release.  Are we intending to ship the RT model import feature in 1.0?  Because, if so, I have some releng work to do to restore it.

Thanks,

Christian

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev



_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger



--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev



_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev


_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev


_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev




--
Camille Letavernier

Senior Software Engineer
EclipseSource Paris

Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19

Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Rémi Schnekenburger
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev


_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev


Back to the top