On 10/11/2010 06:11 AM, Jeff Squyres wrote: 
On Oct 10, 2010, at 7:49 AM, Terry Dontje wrote:


At first glance this sounds like a sane approach but didn't we start with this same approach with 1.5.0?  I know it was kind of required to do it for 1.5.0 but we did go off track with delivery.   I believe to be successful at making a deadline for 1.5.1 we need to consider the following.  Do we think the initial stablization is going to take weeks or months?  

I *think* weeks.  The trunk is pretty stable right now.  But then again, that's why I'm asking here -- what do others think?  Are there half-baked features in the trunk that are not / nowhere near ready for the v1.5.1?
I don't have my half bake features in the trunk, yet :-).

      

        
While we stablize what will be the rules of doing CMRs to 1.5.1?  What will be the rules for doing CMRs to 1.5.1 after stablization?


      

      
I think the CMRs will be pretty much the same.  However, we do reserve the right to have the more aggressive CMRs -- e.g., something "big" can be "ok, Terry/CMR committer, you have the v1.5 branch for 3 days.  Bring your feature over to it."  (might not be necessary if we re-sync, but we still reserve the right to do it ;-) ).



    

    Did I misunderstand the commitment we had for quick dot feature
    releases earlier this year?  The above sounds like we'll repeat the
    1.5.0 release schedule and possibly end up not releasing 1.5.1 until
    8 months from now.  Unless the trunk doesn't have any major
    features/changes I'd almost be more inclined to say the stablization
    of the trunk merge be the 1.5.1 release and plan for a 1.5.2 based
    on CMRs (no CMR no putback to 1.5.2).  However, that is really
    dependent on the merge happening and what amount of wide spread
    changes that end up being put back into the trunk that makes
    backporting to 1.5 branch difficult to impossible.  I would even be
    somewhat supportive of periodic trunk sync ups to alleviate such
    backport pain.

    

    --td

    

      

      

        
--td


On 10/8/2010 5:13 PM, Jeff Squyres wrote:


        

          
As we discussed on the call last week, since there is already a bit of a divergence between the trunk and the v1.5 branch, how's this for a wild idea:

    What if we re-sync the entire trunk to the v1.5 branch, stabilize that,
    and call it v1.5.1?

The assumption here is that it will be [far] easier to just re-sync the trunk to the v1.5 branch than to try to bring over stuff in a piecemeal fashion.

There's a *bunch* of new stuff on the trunk that is not on the v1.5 branch -- there's more than enough "meat" to call it a new release.

*** Put differently: is there anything on the trunk that is *not* ready to go to the v1.5 series?

  


        

        
_______________________________________________
devel mailing list
devel@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.dontje@oracle.com