Hi EMF'ers
Obeo is willing to help taking care of the build, we should have a
"release engineer" quite soon and it could be part of his duty to keep
the EMF build rolling.
That being said, it's unlikely we'll be ready for next week.
Cédric
Le 27/01/2010 16:33, Dave Steinberg a écrit :
Hi Nick,
Thanks very much for pushing this forward, starting work on an
Athena-based EMF build, and investigating alternatives to SearchCVS. It
certainly looks like Athena is a viable option. But as Marcelo and Ian
have said, the issue we still face is that no one seems willing or able
to take care of the builds. I'm afraid it's a pretty acute problem, as
Monday is supposed to be our M5 date. Hopefully the promise of Athena
will prove to be something of an enticement.
Cheers,
Dave
--
Dave Steinberg
Rational Software - IBM Toronto Lab
mailto:davidms@xxxxxxxxxx
 Nick Boldt
---01/26/2010 12:27:35 AM---The SearchCVS / Release Notes is
independent of the PDE/Maven/b3/makefile build technology. Updating
The SearchCVS / Release Notes is independent of the
PDE/Maven/b3/makefile build technology. Updating that database simply
requires updating the RSS feed which the database watches in order to
load new releases.
No one has yet asked that the promote.xml script used in Athena have an
additional optional step to publish information into an RSS feed, but
that's fairly easy to do should it be required. If that's a requirement
of EMF moving to Athena, I'll push such a TODO up the list so that you
can continue to enjoy that feature.
On a related note, Athena now does Helios-style .build files. If you
publish your own file into the Helios cvs repo, you can use Athena's
promote.xml to update that file with the newly published update site
feature versions - it simply replaces the existing list of features'
versions w/ new ones. So, you still have to maintain the file yourself
(eg., adding email contact information and categories) but there's an
automated process to allow you to keep the .build file current. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=287013 for details (until I get around to publishing documentation,
that is). I'm copying dash-dev to announce this because I want to have
some people try it out and see how badly it breaks Helios. I suspect it
should be fine, but regex pattern matching in XML files can be a
dangerous beast sometimes. And yeah, I could have gone the DOM or model
route, but that's where all ya'll modelers could be providing a
patch/replacement. :)
Nick
On Mon, Jan 25, 2010 at 10:57 PM, Marcelo Paternostro
<marcelop@xxxxxxxxxx> wrote:
Very well put Ian.
The issue we face now is to find someone that is willing to take care
of the builds or, at least, to join forces to keep them running. This
person (or people) should then decide the technology to be used and
also the artifacts that are created by the build. A bit more on the
latter, moving to another build implementation like Athena **may**
imply losing, for example, the "Search CVS" and the automated "Release
Notes". I believe many would be sad about this, but, at this very
moment, these services are pointless since we don't have the capability
to produce a new build.
Best regards,
Marcelo Paternostro
IBM Canada Lab
1-905-413-3942
marcelop@xxxxxxxxxx
Kenn,
>From what I understand (and that is usually pretty limited), b3 is
a build technology (same category of technologies as Maven, Ant,
PDE/Build, etc...). The problem here (also faced by many Eclipse
projects) is not the choice of build technology, but rather build
infrastructure. How are the builds being run, how are they propagated,
how are errors reported, who handles the errors, who gives the +1 / -1
to the builds, etc...
I think (again, I could be wrong) this is where Athena enters the
picture. From a technology adoption standpoint, using b3 may make
perfect sense, but I'm not sure it solves the problem that Dave and
Marcelo raised.
Maybe b3 is aimed to bring the build technology and build
infrastructure gap closer together, and if so great! Maybe someone
with more knowledge of the b3 project could comment here.
cheers,
ian
On Mon, Jan 25, 2010 at 6:51 AM, Kenn Hussey <kenn.hussey@xxxxxxxxx> wrote:
It would make more sense (to me) for the build to be migrated to b3.
Kenn
On Mon, Jan 25, 2010 at 5:27 AM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
Dear Vlad ,
I was just signifying the fact that you spoiled the plot of a "good
science fiction movie" which some people might want to watch too. I
tried to keep the constructive tone you used in your note.
Going back to the EMF issue : obviously some people cares about the
build (I do !) and moving it to Athena would ease the integration of
new people to maintain it.
Cédric
Le 25/01/2010 11:15, Vlad Varnica a écrit :
Dear Cedric,
We are not at my children's garden Junior School so please explain your
point of view and don't reply such a way.
Kind Regards,
Vlad,
Cédric Brun wrote:
Spoiler !
Le 25/01/2010 10:58, Vlad Varnica a écrit :
Marcello,
I watched a good science fiction movie named "The day the earth Stood
Still" last week on my SkyBox last week.
Keen Reeve was an Alien named Klaatu" coming to earth to decide how to
save the earth.
He had long talks etc....but at the end his conclusion was that the
only way to save the earth was to get rid of human being and let
animals leave in peace.
Hopefully a professor explained to the Alien that: "all civilizations
only change when they're at the precipice of a crisis. He says human
will change, now that they are really at the edge of destruction".
At the end of the movie the sphere and Klaatu have disappeared. Then
EVERYTHING shuts down - lights, buildings, cars, etc. People
everywhere cautiously emerge.
Do you think there is a parallel between EMF and the edge of
destruction ?
--
------------------------------------
Vlad Varnica
OMONDO
------------------------------------
Marcelo Paternostro wrote:
Hi,
Dave and I have been talking about EMF builds and the issue worry us a
bit. Although most of the work can be automated, the build does require
some attention: from running scripts and checking test results on a
regular basis, to actually maintaining the build in order to provide
new artifacts or fix something that got broken due to changes in a
dependency. Since neither Dave nor I can assume this responsibility,
ideally someone else would step up to task. This person would hopefully
be committed to all parts of code and, for example, make some noise
even if a test focused on a less important piece fails (a test for the
mapping support for example).
An alternative to have a single soul working on this is to gather a
pool of people and share the burden. Dave and I could be members of
this pool, if this makes sense.
Btw, if it helps making this topic a little more exciting, Dave and I
are willing to move the EMF build to Athena (Nick has already done some
of the required work!). Obviously "old build or Athena" is a completely
irrelevant matter if no one cares about EMF builds. If that's indeed
the case, is it OK if EMF doesn't have a new build? All affected
projects, people, and companies are OK with it?
Anyhow, the microphone is open for everyone. Any input is welcome.
Best regards,
Marcelo Paternostro
IBM Canada Lab
1-905-413-3942
marcelop@xxxxxxxxxx
Hi all,
I'm going to be changing jobs at IBM in a week, and as result, working
on EMF will not be part of my "day job." I'd like to remain a committer
and stay involved in the project as much as possible.
One responsibility that I'll need to shed, however, is the EMF Core
build. Mostly this has just meant pushing buttons on the build system
that Nick built, ensuring things work, and manually filling in the gaps
when they don't. But I don't feel I can be the single point of failure
for getting EMF built and promoted anymore.
So I'm wondering if someone else is willing to take primary
responsibility for build stuff, or if we could somehow share it amongst
committers? Also, would it be helpful to finally move to the Athena
Common Build, or to further enhance the existing modeling build? It
would be great if we could have builds automatically run when new
changes are committed and have weekly I builds promoted automatically
if they are clean (no build or test errors). If there's some work
that's needed up-front to make things easier in the future, I'm willing
and able to contribute some effort now. Marcelo has indicated to me
that he's willing to help, too.
Everyone's input would be much appreciated.
Cheers,
Dave
--
Dave Steinberg
Rational Software - IBM Toronto Lab
mailto:davidms@xxxxxxxxxx_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Dash Athena
http://nick.divbyzero.com_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
|
