Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Kepler initial daze
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?

Back to the top