Which itself was renamed from previous
"Juno specific" version (Seems things are constant and steady
enough to justify one document for both Juno and Kepler).
If I've missed anything (or, anything
unclear) let me me know.
Most important, in the master branch
(for Kepler), I have disabled every contribution and will require projects
to re-enable themselves as a sign they are intending to participate in
Kepler (See bug 365738).
The bad news is there is a large "order
effect" here. For example, EMF and GEF must re-enable themselves before
WTP (or nearly anyone else) could correctly aggregate.
The good news is that I put an early
"warm-up I build" in for Eclipse and Equinox (and, yes, enabled
them) and from some quick checks, it appears everyone still builds with
the Platform's Kepler M1 (at least, as of right now, with warm-up) so ...
the point is ... many low level projects such as EMF or GEF could likely
re-enable themselves quickly before any new contributions were made/ready,
thereby enabling your consuming projects to re-enable themselves too. Put
another way, there is no reason to wait until your designated +n day to
re-enable yourself, and if you do, it'd likely complicate getting M1 done.
This complete the 5 steps outlined in
my original note. Transition complete .... now on to business.
Both Kepler M1 and Juno RC1 complete
the same week (final contributions from 8/20 to 8/22). That will be a busy
week, so anything that can be done early, even if done as "warmup"
willl likely help that week complete on time.
David M Williams/Raleigh/IBM@IBMUS
Cross project issues
08/06/2012 12:52 AM
Migrating SimRel files this weekend to
But have not yet update any related documentation or "how to"
information, which I will be working on this week and post again when "all
So, no need to worry about much till then, but ... reserve some time later
in the week for worrying :)
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Migrating SimRel files this weekend to Git
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
Just an FYI that I will be moving the Sim Rel files over to Git this weekend.
It would not really hurt much if you continued to make changes today or
tomorrow ... but, you might have to do them again depending on exact timing.
The build did get back to runnable state with just one feature disabled
and in communication with the team (SOA BPEL) the person to "really
fix" the issue is still out on holiday.
So, we will be close to Juno SR0, but probably not exact.
The hardest part for me this weekend will be updating all the "how
to" wiki pages, etc., so (after Monday) if people see areas I've missed,
let me know.
I'll try to remember to turn off "notifications" as I'm sure
a couple of aggregation builds will fail as I put new system in place,
but if you see any such messages this weekend, you can safely ignore them.
And, thanks Henrik for the reminder to tag the initial version in Git with
JunoSR0 ... I would have forgotten. The final one in CVS was tagged with
I'll be off line this afternoon but will check mail and this list before
actually starting the work this evening, so if anyone has any concerns
or questions, feel free to say.
Kepler initial daze
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
I have turned back on the aggregation builds.
Not surprisingly it failed right away, since, I suspect, many projects
still need to update their URLs to their final Juno release repository.
There are a couple of activities going on over the next week to 10 days,
such that it would be to your advantage to get those up to date in the
next few days. That is, updating so the "Juno Release" builds
Here's an outline of what is quickly coming up (I propose).
First, transition to Git.  I have been exploring and experimenting with
moving the aggregation files and build to Git and am feeling confident
enough to say we'll do it in about a week. So, at some point, let's say
Friday, 8/3, will be the official "cut off" time for CVS changes.
After that, I suspect there will be a little "down time" while
I actually do the move, and get things working again before it'd make sense
to make official changes to your Git files. So, anything not building by
Friday will just be disabled.
Second, change in aggregation build project name.  As we "rethink"
this stuff, as we move to Git, and a new release, it makes sense to change
the name of the projects to a persistent name, that won't change from release
to release, and instead we'll just make persistent branches of those projects.
The name currently proposed for new project will be "org.eclipse.simrel.builds"
which will initially be a "copy" of "org.eclipse.juno.builds"
(done after Friday 8/3).
Third, right after we migrate to Git, and get the build running again with
those Git repos, we will branch master of "org.eclipse.simrel.builds"
to Juno_maintenance. From that point on, master will be for Kepler and
Juno_maintenance for Juno SR1. I expect this all to happen before
Kepler M1 +0 which is 8/10  (And Juno SR1 aggregation starts shortly
after that.  )
Fourth, we need the maintenance branch to be able to build at any time
... so, everyone needs to get and keep that up to date, if anything breaks
from what ever your final release was (which, should be unlikely). But
Fifth, due to some discussions in some bug somewhere , it was decided
that as we start a new release, ALL projects will start off disabled in
the aggregation build. The project team will need to re-enable when they
are ready and committed to Kepler, which should be for M1 for those participating
in Juno. That would be by 8/22 at the latest. Anyone in Juno, but
not in Kepler M1 will be assumed to not be participating in Kepler or having
some troubles. Projects new to Kepler (still) have until M4 (at the latest)
to join the train (but, can join earlier, if they'd like!).
So, a lot is proposed to be happening over the next week. I will keep you
informed along the way, but ... if anyone wants to update your CVS files
one last time, now is the time to do it.
Comments, suggestions, questions, and your cooperation :) will be most