Re: [papyrus-rt-dev] Merging State Machine Diagram Inheritance

[Christian Damus <give.a.damus@xxxxxxxxx>]

Thanks, Rémi,

I specifically did not volunteer you, as I tried to explain 😉, and I very much appreciate your help.  I’m glad to be able to unblock you.  Also, there will be JUnit test coverage coming for these contributions, but there are probably a few other priorities in the way, first.  I shall be happy to reciprocate with some review.

cW

On Feb 22, 2017, 08:39 -0500, Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx>, wrote:

Hi Christian,

As I was volunteered, I reviewed the 2 gerrits this morning ;-) That was a good opportunity for me to understand the modifications and the incoming changes in the way of coding stuff inside state machine diagram. 

Both contributions are OK on my side, I only asked a bunch of questions on top of your code to understand better the implication on my developments. As indicated, I will wait for you to merge the gerrits before rebasing my patch against the canonical policies of the state machine. You already provided equivalent solutions to what I proposed, I will only complete the code for a few corner cases.

I agree for the fact that it is time to merge such contribution.

Cheers,

Rémi  

2017-02-21 21:16 GMT+01:00 Christian Damus <give.a.damus@xxxxxxxxx>:

Hi, Team,

As I alluded to on another thread, I would like to begin the process of merging my changes for inheritance in the state machine diagram to master, for a few reasons:

• it is now at a fairly stable point where we need to start shaking out the bugs (I know they’re in there).  The main use cases in the diagram are implemented
• this cross-cutting concern requires changes in a lot of different places, and as long as these changes are outstanding there is a high probability of conflict with the several other developments going on in the same diagram
• we need considerable lead time before the 0.9 release to stabilize this

So, to that end, I have a couple of Gerrit patches in review:

• Core Component
• Tooling Component

Volunteer(s) for code review will be much appreciated, if we are agreed on merging this stuff this week.  I’ve added Rémi to these gerrits because of the conflict in the canonical strategies that we have already identified, but that doesn’t mean that I am volunteering him!

Happily, this isn’t as big as the Capsule Structure Diagram review was in its day, because much of the infrastructure from that diagram is reused here.

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

--

Remi Schnekenburger

Senior Software Architect / General Manager

EclipseSource Paris

Email: rschnekenburger@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25 
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19

Hangouts: rschnekenburger@xxxxxxxxxxxxxxxxx

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger

Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France

Commercial Register 824 977 516  R.C.S. EVRY

_______________________________________________
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