[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dash-dev] SearchCVS, Release Notes, and Helios .build files (was Re: [emf-dev] EMF Core Build)
|
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.
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
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
Release Engineer :: Dash Athena
http://nick.divbyzero.com