I understand your point and this is largely a lack of management on
my side. So I apologize.
In fact, we made good progresses on the charter and the membership
aspects, and we are almost done on these parts so we hope to publish
these things soon.
But inside the OPEES project, most of the experiments should be done
in 2012. And for some experiments, we need to be able to work on an
infrastructure. We may even be able to submit new
"Polarsys-specific" services to this implementation, like services
based on gPM.
It is perfectly acceptable that the infrastructure is not ready yet,
but the important point is to agree on the fact that OPEES partners
will be able to access the Polarsys infrastructure until the end of
the project. I expect that for these partners, the access would
change on December 21st 2012, which is the end date for OPEES.
If you agree on this, and now that we have users knocking at the
door, we can setup the plan to make the infrastructure accessible.
Hopefully, the things will get better as soon as we set up our
regular Polarsys telco. I am working with Ralph to launch the first
telco either next week or the week after.
OPEES project leader
+33 672 120 226
Le 09/02/12 10:18, Mike Milinkovich a écrit :
my view the problem is that we have no plan. Or at least no
plan that I and the key staff (webmaster, EMO, IP, etc.)
have seen and committed to. I understand that this is a
completely reasonable request on your part, and a key
milestone in gettting started. But it was a surprise to us,
and that is the deeper problem. In the short term, the fact
that it was a surprise means that I have no idea if the
infrastructure is actually ready. Given how busy the Eclipse
Foundation team is, I rather doubt it.
is responsible for creating, communicating and obtaining
commitment to the plan for getting Polarsys up and running?
We need to know what functions the Polarsys team require, by
date. This includes all of the forge functionality, the
project management processes and the IP processes.
such a plan exists and I have missed it, I apologize.
I agree that the next step for the establishment of Polarsys
is that members sign the participation agreement, but we
also need that the OPEES project partners would be able to
do some tests and prepare the migration of some components
migrations towards Polarsys.
Additionally, I think that OPEES members should get access
(with no waranty) to the Polarsys infrastructure or to a
sandbox Polarsys infrastructure so that they can do the
OPEES experiments in the Polarsys context instead of doing
these experiments on other infrastructure.
So I suggest to go forward on these two different topics:
* signing of the membership agreement by the Polarsys
* experimentation of the infrastructure both by the
Polarsys members and OPEES partners.
Such experimentation by OPEES partners which are not
Polarsys members should be limited to some services and for
example may not include the Common Build Infrastructure as
non Polarsys members are not supposed to offer LTS.
Additionally, we must emphasize on the fact that the current
infrastructure is not stable and must be used for test
But we need to find a way to provide a test infrastructure
for test to those OPEES partners who will help populate
Polarsys code base. There is great value that can come from
this OPEES experimentation phase.
As OPEES project leader, I can act as a proxy and tell you
if people asking for access to the infrastructure
effectively ask it in the context of OPEES.
For Mathieu, it is clearly the case: he works for Atos on
Topcased and will test the (technical) migration of some
Topcased components to Polarsys.
OPEES project leader
Le 08/02/12 18:05, Mike Milinkovich a écrit :
far as I know, the Polarsys infrastructure is not ready to
be tested. The group hasn't been formally created, and we
don't have participation agreements in place.
one of the first tasks of the Steering Committee will be
to work with the EMO to plan for the phases of
infrastructure readiness and capabilities.
anyone thinks that I'm misinformed, please let me know.
I've been traveling quite a bit lately, so it is possible
that I am behind on the latest developments.
I am planning to do some tests on the
My first goal is to implement a way to
follow Papyrus development and have the flexibility to
choose which commits I want to keep, and do some
internal commits unrelated to the upstream changes.
I am planning to:
- create a git repo which will be a “clone”
of an Eclipse SVN repo (possibly more simple than
Papyrus at the moment) : this repo will follow the SVN
commits by using svn2git on my machine and pushing the
resulting git commit manually.
- create a branch from this “clone”
- merge some commits from the clone into
the branch and/or do some minors internal commits
- use Hudson+Buckminster to build an update
site from this branch
To do that I need some rights on the
different parts of the infrastructure:
- a git test repo where I have all the
rights needed. If I can create myself a git repo it is
- Some rights on the Hudson so I can add
and configure a build, and ssh access if no
buckminster is currently installed.
What is the process to have those
I am a committer on Papyrus so all the
Eclipse legal formalism should already be OK.
Ce message et les pièces jointes sont
confidentiels et réservés à l'usage exclusif de ses
destinataires. Il peut également être protégé par le
secret professionnel. Si vous recevez ce message par
erreur, merci d'en avertir immédiatement l'expéditeur et
de le détruire. L'intégrité du message ne pouvant être
assurée sur Internet, la responsabilité du groupe Atos
ne pourra être engagée quant au contenu de ce message.
Bien que les meilleurs efforts soient faits pour
maintenir cette transmission exempte de tout virus,
l'expéditeur ne donne aucune garantie à cet égard et sa
responsabilité ne saurait être engagée pour tout dommage
résultant d'un virus transmis.
This e-mail and the documents attached are confidential
and intended solely for the addressee; it may also be
privileged. If you receive this e-mail in error, please
notify the sender immediately and destroy it. As its
integrity cannot be secured on the Internet, the Atos
group liability cannot be triggered for the message
content. Although the sender endeavors to maintain a
computer virus-free network, the sender does not warrant
that this transmission is virus-free and will not be
liable for any damages resulting from any virus
polarsys-infra mailing list