[qvto-dev] QVTo progress for Kepler

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Christopher

[Please subscribe to qvto-dev].

I am afraid that I'm losing faith in Nicolas Rouquette's mega-patch; now 
that we're past M4, time is running out to get a stable solution for M6. 
Since the changes apparently need changes to MDT/OCL, these may be 
particularly challenging and time consuming and will probably mandate 
rework. Having yet to see any code concerning the OCL impact this is a 
huge unknown. I just know from bitter experience that any change to the 
legacy MDT/OCL has horrible unforeseen ripples.

So if Nicolas' patch is unlikely for M6, we are now looking at it for 
Kepler+1, by which time Adolfo's rework to exploit Xtext, the OCL pivot 
model, caches etc may be viable, so effort on revising the existing code 
base may be hard to justify.

We have waited a year for the mega-patch and since your patches are 
available and probably need limited effort to get into M5/M6/Kepler, I 
don't think we should continue to make your patches wait for the 
mega-patch. If the mega-patch appears, it will have to be rebased on top 
of your patches.

[Apologies, if you have already done this.]

Please create a planning bugzilla blocked by all 'your' bugzillas, and 
attach a simple spreadsheet showing each of your:
bug number,
(optionally reworded) bug summary description,
brief (one sentence) summary of the fixes achieved
description of any downsides of the fix
names of any JUnit tests

Group inexplicably linked fixes as a single multi-line spreadsheet entry

Sequence the fixes in dependency order (directly applicable first, most 
dependent on other fixes last).

I assume that all the changed code lines are written by you/copied from 
elsewhere in the existing code, and that your employer/university is 
happy to permit your changes to be contributed under the EPL. Please 
confirm.

If we get these in for Kepler, we can propose you as a QVTo committer 
starting after Kepler. It's probably best for you to start after Kepler, 
since new committers often make stupid mistakes, which there is plenty 
of time to resolve after Kepler. Before Kepler we will be in the release 
ramp down stages where mistakes are less welcome.

    Regards

        Ed Willink