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 >>>>>> >>>>>> jsquy...@cisco.com >>>>>> >>>>>> For corporate legal information go to: >>>>>> >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> >>>>>> de...@open-mpi.org >>>>>> 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 >>>>> >>>>> de...@open-mpi.org >>>>> 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.don...@oracle.com >>> >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> 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 >> de...@open-mpi.org >> 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.don...@oracle.com > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
