Re: [OMPI devel] 1.5 plans

[Ralph Castain]

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.
>> 

Re: [OMPI devel] 1.5 plans

[Terry Dontje]

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 

Re: [OMPI devel] 1.5 plans

[Terry Dontje]

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





--
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 

Re: [OMPI devel] 1.5 plans

[Jeff Squyres]

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.

> 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


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/