Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Incubation component minutes

If my brainstorming is being called a "strategy", then yes. The developer/developers working on an incubation project for, say, "1.1.x", would need to decide at the branch-point of EL 2.0, if they want to switch target versions, continue targeting 1.1.x, branch at that time, or if they will consider branching later.

If the incubation projects are active, this shouldn't be a big decision. However, if work lags on them (weeks or months between updates) then this presents an issue - they could potentially always be playing catch-up (with either storage strategy).

I don't see an ideal solution (under trunk, or not), too much depends upon how this sandbox will actually be used.

To me this points out the need to be very clear as we define what an active incubation project entails. What gets in, how it is accessed, what happens when an incubation project falls inactive, how they will be supported (what is the support-threshold? 1, 5, 20 users?). We need to be very clear about the lifecycle of these projects. Once we have those answers, which way is least disruptive will be clearer.

-Eric

Tom Ware wrote:
Does the suggested strategy mean that every time we branch, we have to decide individually for each incubation project whether to branch it?

Eric Gwin wrote:
Gordon,

I think you are misunderstanding me. I am not talking wholly about development decisions, but also about the repercussions due to the constraints of the tools. Subversion WILL branch everything under trunk when trunk branches. Therefore

trunk
 \--incubation
          \--- proj1
           \---proj2

will result in branched incubation projects. Thus forcing a maintenance of two streams (unless one is abandoned - Which forces deletions, or clutter).

However, subversion also allows mixed checkout, so where incubation resides in the repository makes no difference to where it is checked out in a view (nor should it effect checkout in an IDE environment). For instance, a project that wants to maintain close dev ties to trunk, could reside in an incubation project outside of trunk:

\-- trunk
\- incubation
        \--- myproj

but still be developed side-by-side in a view like:

trunk
\---foundation
 \-- myproj
  \-- ...

You are correct that we would need to think about branching strategies for incubation.. perhaps duplicating the project at branch-time would work.

trunk                                                     trunk
\--incubation                   ------->             \--incubation
\--- myproj \---myproj1.1 \---myproj2.0

-Eric

Gordon Yorke wrote:
Branching incubation projects with the EclipseLink streams will in no way force these projects to maintain multiple streams. It will be the choice of the individual projects if they want to maintain compatibility with a previous EclipseLink stream. Eliminating the branching does however produce barriers to the incubation projects that may wish to have multiple streams or those that may wish to develop within a particular stream. If an incompatibility is introduced in the trunk projects with branches will also have the option of returning to a previous stream while continuing to develop new functionality in the trunk. It should be expected that many of these incubation projects will have lifecycles that include multiple main stream branches.
--Gordon


Eric Gwin wrote:
I think that having it under trunk is a bad idea - it simply adds more maintenance headaches and clutters the tree.

I'm assuming that the incubation project(s) will be worked on by a few key committers as time permits. This means that getting the project "EclipseLink ready" could take a while, and resources will be limited.

Do we really want to force maintenance on multiple branches, or leave abandoned copies out there?

Not to mention that conceptually everything under trunk is part of our "current" development release, just like everything under branches/1.0 is everything for our 1.0.x release stream. The whole intent of the "incubation" project is that it isn't part of a release.

I still think it is easier and makes more sense to store it above the trunk (actually the same level as the trunk) and maintain a document that says.. This incubation component is being developed to run using "x.x.x" of EclipseLink (among other things like what it is supposed to do, how to use it, dependencies it needs, etc.)

Then once it reaches production quality it is folded into EclipseLink and the incubation project is removed. and it branches along with everything else.

-Eric

Peter Krogh wrote:
I wasn't clear in my first email. We all agreed that we should create the componant. The discussion point was around whether the directory should be in trunk or parrallel. Doug has proposed trunk. Any objections? I know that there were a couple of concerns brought up durring the meeting about what that means to branching.



-----Original Message-----
From: Douglas Clarke Sent: Thursday, December 04, 2008 9:56 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: RE: [eclipselink-dev] Incubation component minutes


I believe Tom's topics listed below should be clearly addressed in the Wiki page each incubation project/component maintains.

I also believe that these should incubate within trunk. It will be up to each owner to manage the state of the incubation effort when we branch. In general I would see these as remaining in trunk until they mature into the main code line.

Doug

-----Original Message-----
From: Tom Ware Sent: Wednesday, December 03, 2008 4:16 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Incubation componant minutes


We also need to identify what information should be provided for each incubation component. (perhaps in a readme)

- What version does it work with
- Any build instructions
- Any usage documentations
- Other things?

Peter Krogh wrote:
During todays call we discusses the incubation idea, proposed by Doug, at length.

Some discussion points arose.

Incubation Componant
Should the incubation directory be under trunk or parrallel to trunk?
    How to handle 3rd party dependancies?
I assume that a consumer of the incubation code would need to download the dependancy themselves, as opposed to opening CQs.

Any others?
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



Back to the top