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
--
Oracle
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 <mailto:terry.don...@oracle.com>
