[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[qvto-dev] QVTo progress for Kepler
|
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