| Small note - it is probably of value to tag the Juno_maintenance with "Juno" (or somesuch) to get a stable point for the release (and then tag it again with "Juno RC1"). This to make it possible at any point to see which commit was used for the respective aggregations.
Sorry for the noise if I am pointing out the obvious...
On Aug 1, 2012, at 2:44, David M Williams wrote: 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 again.
Here's an outline of what is quickly
coming up (I propose).
First, transition to Git. [1] 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. [1] 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 [2]
(And Juno SR1 aggregation starts shortly after that. [3] )
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 [4], 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 welcome.
Thanks,
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=359240
[2] http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule
[3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#SR1
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=365738
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
