Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] 1.5 plans
From: Ralph Castain (rhc_at_[hidden])
Date: 2010-12-01 00:16:48


I don't have a real opinion here as the work I'm doing doesn't rely on stable releases.

That said, I wanted to clarify something hinted at in earlier comments. I killed the ORTE refresh ticket -not- because I believe it doesn't belong in the 1.5 series, or any other release. I killed it because it was no longer relevant - "refreshing" ORTE won't really work at this point as too many other changes in OPAL and OMPI would be required to make the "new" ORTE work.

The question really is - do we re-branch the trunk for a 1.5.x release, or branch the trunk for a 1.7.0 release?

Having a ticket that specifically referred to refreshing ORTE for 1.5.x was inaccurate and might lead to confusion, so I removed it. That action should definitely not be taken as pushing the group one way or the other on this matter.

HTH
Ralph

On Nov 30, 2010, at 8:28 AM, Terry Dontje wrote:

> On 11/30/2010 10:10 AM, Joshua Hursey wrote:
>>
>> (Insert jab at the definition of 'quickly' when talking about OMPI releases)
>>
>> >From the way I read Jeff's original email, it seems that we are trying to get v1.5 stable so we can start v1.7 in the next few months (3-5). The C/R functionality on the trunk is significantly different than that on the v1.5 (and more so with v1.4). So brining these features over the v1.5 branch will require a CMR that will look like re-syncing to the trunk (it requires the ORTE refresh, and a couple other odds and ends). Since the ORTE refresh was killed due to the size of the feature, so has the C/R features. So even though the v1.5 is a feature branch, the C/R feature is locked out of it at the moment and pushed to v1.7.
>>
> Yeah, we have successfully deadlocked ourselves. We got features that cannot go in because they rely on stuff we refuse to bringover because of stability but at the same time cannot force 1.5 to be 1.6 because 1.5 isn't stable enough itself. Quite a pickle. I still believe a refresh/sync of trunk to 1.5 makes sense. The only other solution is to start 1.7 and put 1.5 to bed. Unfortunately there are some implications for Oracle if all the current stuff is put into 1.7 instead of 1.5.
>> So, from my perspective, there is now a push to hurry up on the v1.7 so users will have a release branch with the latest-n-greatest C/R functionality. Releasing v1.7 next summer would be fine with me, but pushing it further into the future seems bad to me.
>>
> Well, I think we need to really think about this carefully to make sure we do not end up in the same situation 6 months from now.
>> As a side comment:
>> The stable branch is a great idea for the production side of the house since it is more carefully crafted and maintained. The feature branch is a great idea for the researchers in the group to gain exposure for new features, and enhancements on old features (many of these require changes to internal APIs and data structures). From my perspective, a slow moving feature branch is no longer that useful to the research community since it becomes more and more painful to synchronize the trunk and branch the longer it takes for the feature branch to stabilize for release. So the question often becomes why bother. But this a longer discussion for another time maybe.
>>
> IMO, the problem is we ended up not stablizing 1.5 quick enough thus causing so great of a divergence that we are in the pickle we are now. The whole idea was we were to push stuff into 1.5 quickly. If we cannot do that then we may want to reconsider how we handle releases again :-(.
>
> --td
>> -- Josh
>>
>> On Nov 30, 2010, at 9:36 AM, Terry Dontje wrote:
>>
>>> On 11/30/2010 09:00 AM, Jeff Squyres wrote:
>>>> On Nov 30, 2010, at 8:54 AM, Joshua Hursey wrote:
>>>>
>>>>
>>>>> Can you make a v1.7 milestone on Trac, so I can move some of my tickets?
>>>>>
>>>> Done.
>>>>
>>> I have a question about Josh's recent ticket moves. One of them mentions 1.5 is stablizing quickly Josh can you clarify what you mean by quickly because I think there will be a 1.5 release 3-6 months from now. So does that fall into your quickly perspective?
>>>
>>> --td
>>>>> Some are CMRs, but a couple are defects, with fixes in development, that without those CMRs cannot be moved to v1.5.
>>>>>
>>>>> Thanks,
>>>>> Josh
>>>>>
>>>>>
>>>>> On Nov 29, 2010, at 11:43 AM, Jeff Squyres wrote:
>>>>>
>>>>>
>>>>>> I'm about 2 weeks late on this email; apologies. SC and Thanksgiving got in the way.
>>>>>>
>>>>>> Per a discussion on the devel teleconf nearly 3 weeks ago, we have decided what to do with the v1.5 series:
>>>>>>
>>>>>> - 1.5.1 will be a bug fix release. There's 2 blocker bugs right now that need to be reviewed; those and the currently ready-to-commit major CMR are all that is planned for 1.5.1. Hopefully, they could be ready by tonight.
>>>>>>
>>>>>> - 1.5.2 (and successive releases) will be "normal" feature releases. There's a bit of divergence between the trunk and the v1.5 branch, meaning that some porting of features may be required to get over to the v1.5 branch (FWIW, I think that many things will not require much porting at all -- but some will). Many of the CMRs filed against v1.5.2 are still relevant; *some* of the features/bugs are still relevant. We'll start [re-]examining the v1.5.2 tickets in more detail soon. So feel free to apply to have your favorite feature brought over to the v1.5 branch. Bigger features may be kept in the wings for v1.7 (e.g., the wholesale ORTE refresh for v1.5.x has been axed and will wait until v1.7). There is a bunch of affinity work occurring on the trunk (and/or in hg branches) right now; we plan to bring all that stuff in to the v1.5 series when ready (probably 3+ months at the earliest -- especially with the December holidays delaying everything). Once that's done, !
>> we!
>>>> !
>>>>
>>>>> ca!
>>>>>
>>>>>> n then probably start thinking about wrapping up the v1.5 series, converting it to its stable counterpart (1.6), and then branching for v1.7.
>>>>>>
>>>>>> --
>>>>>> Jeff Squyres
>>>>>>
>>>>>> jsquyres_at_[hidden]
>>>>>>
>>>>>> For corporate legal information go to:
>>>>>>
>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> devel mailing list
>>>>>>
>>>>>> devel_at_[hidden]
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------------
>>>>> Joshua Hursey
>>>>> Postdoctoral Research Associate
>>>>> Oak Ridge National Laboratory
>>>>>
>>>>> http://users.nccs.gov/~jjhursey
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>>
>>>>> devel_at_[hidden]
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>
>>> --
>>> <ATT00001.gif>
>>> Terry D. Dontje | Principal Software Engineer
>>> Developer Tools Engineering | +1.781.442.2631
>>> Oracle - Performance Technologies
>>> 95 Network Drive, Burlington, MA 01803
>>> Email terry.dontje_at_[hidden]
>>>
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> ------------------------------------
>> Joshua Hursey
>> Postdoctoral Research Associate
>> Oak Ridge National Laboratory
>> http://users.nccs.gov/~jjhursey
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> <Mail Attachment.gif>
> Terry D. Dontje | Principal Software Engineer
> Developer Tools Engineering | +1.781.442.2631
> Oracle - Performance Technologies
> 95 Network Drive, Burlington, MA 01803
> Email terry.dontje_at_[hidden]
>
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel