David,
I've updated EclipseLink's aggregation build file to our release repo (from the
last milestone - they are identical repos, but in different locations).
-Eric
Comments on your points are inline:
On 31/07/2012 8:44 PM, David M Williams wrote:
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.
1) Awesome. I'm looking forward to Git. As mentioned EclipseLink should be
"good-to-go"
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).
2) Makes sense, I have no qualms about the name of the project. I assume the
git repo
would actually be called "org.eclipse.simrel.builds.git" right?
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] )
3) Ok
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 ...
4) Again, okay. But I think we need to talk due to WTP's pickup of EclipseLink
(soon), I'm not certain how it is decided what to include, and duplicates can
easily ensue if we get out-of-sync.
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!).
5) EclipseLink will be in Kepler, but we've just completed a migration to Git,
and we've decided we won't be ready to contribute a new build for Kepler M1.
Instead we were planning on leaving the Juno contrib in place, until M2. Is
this decision going to result in extra admin steps? Is there any way
EclipseLink could be left active, as I will also be away on vacation during M1,
so won't be available to activate it?
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
