Sergey,
Perhaps is not very a weighty opinion, but I personally have
interest in having QVTo in the release train. As a experienced QVTo
and Eclipse user, I (we) may manage to make QVTo components work in
any future Eclipse release. However, as a guy who has participated
in the OCL and QVT OMG specification evolution, I believe that not
having QVTo in the release train is damaging for the QVT
specification...
As Philipp mentioned is good for the the community having strong
projects in the train which cover OMG specifications ... Open
specifications need (specially) from open tools to make them evolve,
and if they don't evolve they won't never be eventually accepted as
a standard specifications, and standardised specifications are a
crucial step in software engineering. I think that not having a
evolution of the QVTo project is not good, but not having the QVTo
into the release train could be a harmful fact (People could think
that the project and specification is dead). The former could be
expensive (need full time people involved into the project), but the
latter could be more tenable (fix dependencies ranges, aggregator
files, etc) with no extraordinary effort.
I confess that I'm the first one who could do more in having such a
things happen (make QVTo and QVT spec evolve ) but this is not the
question now (Unfortunately I don't have the decision on what I
spend my daily work time). The question for those who think that QVT
has settled a good basis for model to model transformations should
consider the negative impact of not including the QVTo project into
the release train...
Since, as said, I think that this effort is tenable and that's the
reason why I've offered my help (and I'm actually doing off-line) to
Sergey WRT sharing my experience/advises in any inconvenience about
the releng he may find in making the QVTo project contribute to the
Juno release train. I'm not sure if this will suffice, but I
encourage you (Sergey) and everyone interested in make this happen.
P.S: I also want to be grateful to Nicolas generosity, in this case.
I hope as him we all have QVTo components in the official Juno
repository.
Best Regards,
Adolfo.
El 19/12/2011 9:06, Sergey Boyko escribió:
Hi Philipp,
Problem with QVTo participation on Juno release train comes
from the fact that I didn't get clear response whether somebody
requires that participation.
When we discussed with Nicolas (in August) patch from NASA we
decided that QVTo release for Indigo is the right target to
merge the patch to (I prepared maintenance branch for that).
I also expect some input from re-istablished GMF Tooling
project but there was nothing.
Without clear interest of QVTo participating in Juno realease
train I didn't see the need to perform all the administrative
steps to keep project on train.
Regards,
Sergey Boyko
On Sat, Dec 17, 2011 at 4:55 PM, Philipp
W. Kutter | Montages AG <kutter@xxxxxxxxxxxx>
wrote:
Perfect!
I wish you all Happy Holidays!
It is a great feeling that the OMG standards based projects
are going strong and will all be on the Juno releasse train!
If there is a doubt in the future that any of these projects
will not be on the release train, simply because nobody is
there to fulfill the formalities of the project or the details
of the newest build project, we can always help. As Miles
mentions, this may need to add some people of other modeling
projects to the committer teams.
Could the modeling PMC send out a mail and ask the modeling
teams
a) who sees a risk they will not be on the release train,
simply because of lack to fulfill the formalities and the
build project
b) who would volunteer to help out for other projects.
As well, it might be a good policy, to have a backup plan, if
a component lead is either not available, or ill, or otherwise
gone in the very moment he needs to promote the project.
Immagine an important project, with lots of dependencies does
not release, simply because the component lead is
in-available. The costs can be huge.
Thanks for the great work of the Eclipse Foundation,
Philipp
On 17.12.2011 01:44, Ed Willink wrote:
Hi Miles
There is no need to panic. In view of some delicacies,
considerable correspondence has happened off-list.
Nicolas Rouquette has now resolved both the problem and
the delicacies by his open email to these lists that you
must have missed.
Thanks to Nicolas' generosity, QVTo will be available in
Juno supported by the existing QVTo team.
The only process exception that may be needed is
tolerance of a one or two day tardiness in setting the
contribution flag.
I'm sure we all wish to thank Nicolas for being so
helpful to Eclipse. Thank you Nicolas.
Regards
Ed Willink
On 16/12/2011 23:57, Miles Parker wrote:
Philipp,
You should identify QVTO leadership, which means M2M
nee MMT, so that they can make the change in their
portal. (This of course would have to be in the middle
of a project renaming!) That would require all of MMT
to join train, I don't know if it's possible to do
this more fine-grained than that. PMC can flip the bit
for MMT, but I don't think we should do that
unless/until we have support from project leadership
or at least active committers if they exist. Comments?
William, I'm cc'ing you because I note that you have
contact with Frédéric Jouault who is project lead..?
Perhaps you could pass on his email to Phillip.
FWLIW, I'll support any process exception if
needed/possible once that is sorted out. Phillip,
thanks for taking the initiative on this. Why don't
you report back to PMC list as you make progress?
cheers,
Miles
On Dec 16, 2011, at 12:29 PM, Philipp W. Kutter |
Montages AG wrote:
Dear PMC.
I would like to notify that QVTO should flip the bit
for Juno. I hope
this has already been done by the QVTO team itself.
In the unexpected case, that the current QVTO team
will not have time to
trigger the newest ways of building the QVTO, I can
guarantee
development time from the GMF Tolling component lead
Michael Golubev,
who knows well the newest ways of building.
As well, there is a cummulative patch from Nicolas
Rouquette, which we
would love to integrate in the new build, if the
QVTO team has not yet done.
The GMF Tooling project has a strong dependency on
QVTO and would fail
in their efforts to do their releases in the future,
if QVTO build fails.
As well, the sponsor of the 3 FTE working on GMF
tooling requests that
GMF Tooling as well as the project it depends on are
remaining in Juno,
so we have a multiyear 3 FTE sponsorship at risk, if
this does not happen.
We want to do all to support the current team to do
the Juno builds.
There is a budget from Nicolas Rouquette and us,
which would offer $
2000 to who ever in the QVTO team wants to do this.
And we support with
development time from the 3 FTE working on GMF
Tooling, if needed.
Please forward this message as well to the QVTO
team, whom I do not know
personally. Please assure them of our full support.
I did not find a mailing list for them.
And, as today is the deadline, please accept this
notification, even if
formally it comes from the wrong side.
Regards,
Philipp
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1890 / Virus Database: 2108/4684 -
Release Date: 12/16/11
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|