Re: [OMPI devel] RFC: standardize verbosity values

[Gilles Gouaillardet]

Nathan,

i think it is a good idea to use names vs numeric values for verbosity.

what about using "a la" log4c verbosity names ?
http://sourceforge.net/projects/log4c/

static const char* const priorities[] = {
"FATAL",
"ALERT",
"CRIT",
"ERROR",
"WARN",
"NOTICE",
"INFO",
"DEBUG",
"TRACE",
"NOTSET",
"UNKNOWN"
};

Cheers,

Gilles

On 5/30/2015 1:32 AM, Nathan Hjelm wrote:

At the moment we have a loosely enforced standard for verbosity
values. In general frameworks accept anything in the range 0 - 100 with
few exceptions. I am thinking about adding an enumerator for verbosities
that will accept values in this range and certain named constants which
will match with specific verbosity levels. One possible set: none - 0,
low - 25, med - 50, high - 75, max - 100. I am open to any set of named
verbosities.

Thoughts?

-Nathan



___
devel mailing list
de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2015/05/17468.php

Re: [OMPI devel] RFC: standardize verbosity values

[Ralph Castain]

Could we maybe narrow it down some? If we are going to do it, let’s not make 
the mistake of the MCA param system and create so many levels. Nobody can 
figure out the right gradation as it is just too fine grained.

I think Nathan’s proposal is the max that makes sense.

I’d also like to see us apply the same logic to the MCA param system. Let’s 
just define ~4 named levels and get rid of the fine grained numbering.


> On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet  wrote:
> 
> Nathan,
> 
> i think it is a good idea to use names vs numeric values for verbosity.
> 
> what about using "a la" log4c verbosity names ?
> http://sourceforge.net/projects/log4c/ 
> 
> 
> static const char* const priorities[] = {
> "FATAL",
> "ALERT",
> "CRIT",
> "ERROR",
> "WARN",
> "NOTICE",
> "INFO",
> "DEBUG",
> "TRACE",
> "NOTSET",
> "UNKNOWN"
> };
> 
> Cheers,
> 
> Gilles
> 
> On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
>> At the moment we have a loosely enforced standard for verbosity
>> values. In general frameworks accept anything in the range 0 - 100 with
>> few exceptions. I am thinking about adding an enumerator for verbosities
>> that will accept values in this range and certain named constants which
>> will match with specific verbosity levels. One possible set: none - 0,
>> low - 25, med - 50, high - 75, max - 100. I am open to any set of named
>> verbosities.
>> 
>> Thoughts?
>> 
>> -Nathan
>> 
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org 
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel 
>> 
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/05/17468.php 
>> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17472.php

Re: [OMPI devel] RFC: standardize verbosity values

[Gilles Gouaillardet]

so what about :

static const char* const priorities[] = {
"ERROR",
"WARN",
"INFO",
"DEBUG",
"TRACE"
};

and merge debug and trace if there should be only 4

Cheers,

Gilles


On Monday, June 8, 2015, Ralph Castain  wrote:

> Could we maybe narrow it down some? If we are going to do it, let’s not
> make the mistake of the MCA param system and create so many levels. Nobody
> can figure out the right gradation as it is just too fine grained.
>
> I think Nathan’s proposal is the max that makes sense.
>
> I’d also like to see us apply the same logic to the MCA param system.
> Let’s just define ~4 named levels and get rid of the fine grained numbering.
>
>
> On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet  > wrote:
>
>  Nathan,
>
> i think it is a good idea to use names vs numeric values for verbosity.
>
> what about using "a la" log4c verbosity names ?
> http://sourceforge.net/projects/log4c/
>
> static const char* const priorities[] = {
> "FATAL",
> "ALERT",
> "CRIT",
> "ERROR",
> "WARN",
> "NOTICE",
> "INFO",
> "DEBUG",
> "TRACE",
> "NOTSET",
> "UNKNOWN"
> };
>
> Cheers,
>
> Gilles
>
> On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
>
> At the moment we have a loosely enforced standard for verbosity
> values. In general frameworks accept anything in the range 0 - 100 with
> few exceptions. I am thinking about adding an enumerator for verbosities
> that will accept values in this range and certain named constants which
> will match with specific verbosity levels. One possible set: none - 0,
> low - 25, med - 50, high - 75, max - 100. I am open to any set of named
> verbosities.
>
> Thoughts?
>
> -Nathan
>
>
>
>
> ___
> devel mailing listde...@open-mpi.org 
> 
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/05/17468.php
>
>
>  ___
> devel mailing list
> de...@open-mpi.org 
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/06/17472.php
>
>
>

Re: [OMPI devel] RFC: standardize verbosity values

[KAWASHIMA Takahiro]

> static const char* const priorities[] = {
> "ERROR",
> "WARN",
> "INFO",
> "DEBUG",
> "TRACE"
> };

+1

I usually use these levels.

Typical usage:

ERROR:
  Print an error message on returning a value other than
  OMPI_SUCCESS (and OMPI_ERR_TEMP_OUT_OF_RESOURCE etc.).

WARN:
  This does not indicate an error. But users/developers should
  be aware on debugging/tuning. For example, network-level
  timeout, hardware queue full, buggy code.
  Often used with OMPI_ERR_TEMP_OUT_OF_RESOURCE.

INFO:
  Information that may be useful for users and developers.
  Not so verbose. Output only on initialization or
  object creation etc.

DEBUG:
  Information that is useful only for developers.
  Not so verbose. Output once per MPI routine call.

TRACE:
  Information that is useful only for developers.
  Verbose. Output more than once per MPI routine call.

Regards,
KAWASHIMA Takahiro

> so what about :
> 
> static const char* const priorities[] = {
> "ERROR",
> "WARN",
> "INFO",
> "DEBUG",
> "TRACE"
> };
> 
> and merge debug and trace if there should be only 4
> 
> Cheers,
> 
> Gilles
> 
> 
> On Monday, June 8, 2015, Ralph Castain  wrote:
> 
> > Could we maybe narrow it down some? If we are going to do it, let’s not
> > make the mistake of the MCA param system and create so many levels. Nobody
> > can figure out the right gradation as it is just too fine grained.
> >
> > I think Nathan’s proposal is the max that makes sense.
> >
> > I’d also like to see us apply the same logic to the MCA param system.
> > Let’s just define ~4 named levels and get rid of the fine grained numbering.
> >
> >
> > On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet  > > wrote:
> >
> >  Nathan,
> >
> > i think it is a good idea to use names vs numeric values for verbosity.
> >
> > what about using "a la" log4c verbosity names ?
> > http://sourceforge.net/projects/log4c/
> >
> > static const char* const priorities[] = {
> > "FATAL",
> > "ALERT",
> > "CRIT",
> > "ERROR",
> > "WARN",
> > "NOTICE",
> > "INFO",
> > "DEBUG",
> > "TRACE",
> > "NOTSET",
> > "UNKNOWN"
> > };
> >
> > Cheers,
> >
> > Gilles
> >
> > On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
> >
> > At the moment we have a loosely enforced standard for verbosity
> > values. In general frameworks accept anything in the range 0 - 100 with
> > few exceptions. I am thinking about adding an enumerator for verbosities
> > that will accept values in this range and certain named constants which
> > will match with specific verbosity levels. One possible set: none - 0,
> > low - 25, med - 50, high - 75, max - 100. I am open to any set of named
> > verbosities.
> >
> > Thoughts?

Re: [OMPI devel] RFC: standardize verbosity values

[Nathan Hjelm]

That would work. The standard verbosity levels could be one of those
values but allow any number in the interval [0,100] or any of none,
error, warn, info, debug, and trace. The standard levels could be
defined as:

enum {
MCA_BASE_VERBOSE_NONE  = 0,
MCA_BASE_VERBOSE_ERROR = 1,
MCA_BASE_VERBOSE_WARN  = 10,
MCA_BASE_VERBOSE_INFO  = 20,
MCA_BASE_VERBOSE_DEBUG = 40,
MCA_BASE_VERBOSE_TRACE = 60,
MCA_BASE_VERBOSE_MAX   = 100,
};

static mca_base_var_enum_value_t verbose_values[] = {
{"none",   MCA_BASE_VERBOSE_NONE},
{"error",  MCA_BASE_VERBOSE_ERROR},
{"warn",   MCA_BASE_VERBOSE_WARN},
{"info",   MCA_BASE_VERBOSE_INFO},
{"debug",  MCA_BASE_VERBOSE_DEBUG},
{"trace",  MCA_BASE_VERBOSE_TRACE},
{NULL, -1}
};

-Nathan

On Tue, Jun 09, 2015 at 12:42:05AM +0900, KAWASHIMA Takahiro wrote:
> > static const char* const priorities[] = {
> > "ERROR",
> > "WARN",
> > "INFO",
> > "DEBUG",
> > "TRACE"
> > };
> 
> +1
> 
> I usually use these levels.
> 
> Typical usage:
> 
> ERROR:
>   Print an error message on returning a value other than
>   OMPI_SUCCESS (and OMPI_ERR_TEMP_OUT_OF_RESOURCE etc.).
> 
> WARN:
>   This does not indicate an error. But users/developers should
>   be aware on debugging/tuning. For example, network-level
>   timeout, hardware queue full, buggy code.
>   Often used with OMPI_ERR_TEMP_OUT_OF_RESOURCE.
> 
> INFO:
>   Information that may be useful for users and developers.
>   Not so verbose. Output only on initialization or
>   object creation etc.
> 
> DEBUG:
>   Information that is useful only for developers.
>   Not so verbose. Output once per MPI routine call.
> 
> TRACE:
>   Information that is useful only for developers.
>   Verbose. Output more than once per MPI routine call.
> 
> Regards,
> KAWASHIMA Takahiro
> 
> > so what about :
> > 
> > static const char* const priorities[] = {
> > "ERROR",
> > "WARN",
> > "INFO",
> > "DEBUG",
> > "TRACE"
> > };
> > 
> > and merge debug and trace if there should be only 4
> > 
> > Cheers,
> > 
> > Gilles
> > 
> > 
> > On Monday, June 8, 2015, Ralph Castain  wrote:
> > 
> > > Could we maybe narrow it down some? If we are going to do it, let’s not
> > > make the mistake of the MCA param system and create so many levels. Nobody
> > > can figure out the right gradation as it is just too fine grained.
> > >
> > > I think Nathan’s proposal is the max that makes sense.
> > >
> > > I’d also like to see us apply the same logic to the MCA param system.
> > > Let’s just define ~4 named levels and get rid of the fine grained 
> > > numbering.
> > >
> > >
> > > On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet  > > > wrote:
> > >
> > >  Nathan,
> > >
> > > i think it is a good idea to use names vs numeric values for verbosity.
> > >
> > > what about using "a la" log4c verbosity names ?
> > > http://sourceforge.net/projects/log4c/
> > >
> > > static const char* const priorities[] = {
> > > "FATAL",
> > > "ALERT",
> > > "CRIT",
> > > "ERROR",
> > > "WARN",
> > > "NOTICE",
> > > "INFO",
> > > "DEBUG",
> > > "TRACE",
> > > "NOTSET",
> > > "UNKNOWN"
> > > };
> > >
> > > Cheers,
> > >
> > > Gilles
> > >
> > > On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
> > >
> > > At the moment we have a loosely enforced standard for verbosity
> > > values. In general frameworks accept anything in the range 0 - 100 with
> > > few exceptions. I am thinking about adding an enumerator for verbosities
> > > that will accept values in this range and certain named constants which
> > > will match with specific verbosity levels. One possible set: none - 0,
> > > low - 25, med - 50, high - 75, max - 100. I am open to any set of named
> > > verbosities.
> > >
> > > Thoughts?
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17475.php


pgpVFYxsar0oC.pgp
Description: PGP signature

Re: [OMPI devel] RFC: standardize verbosity values

[Ralph Castain]

So how is the user going to specify these? -mca oob_base_verbose debug?

> On Jun 8, 2015, at 9:11 AM, Nathan Hjelm  wrote:
> 
> 
> That would work. The standard verbosity levels could be one of those
> values but allow any number in the interval [0,100] or any of none,
> error, warn, info, debug, and trace. The standard levels could be
> defined as:
> 
> enum {
>MCA_BASE_VERBOSE_NONE  = 0,
>MCA_BASE_VERBOSE_ERROR = 1,
>MCA_BASE_VERBOSE_WARN  = 10,
>MCA_BASE_VERBOSE_INFO  = 20,
>MCA_BASE_VERBOSE_DEBUG = 40,
>MCA_BASE_VERBOSE_TRACE = 60,
>MCA_BASE_VERBOSE_MAX   = 100,
> };
> 
> static mca_base_var_enum_value_t verbose_values[] = {
>{"none",   MCA_BASE_VERBOSE_NONE},
>{"error",  MCA_BASE_VERBOSE_ERROR},
>{"warn",   MCA_BASE_VERBOSE_WARN},
>{"info",   MCA_BASE_VERBOSE_INFO},
>{"debug",  MCA_BASE_VERBOSE_DEBUG},
>{"trace",  MCA_BASE_VERBOSE_TRACE},
>{NULL, -1}
> };
> 
> -Nathan
> 
> On Tue, Jun 09, 2015 at 12:42:05AM +0900, KAWASHIMA Takahiro wrote:
>>> static const char* const priorities[] = {
>>>"ERROR",
>>>"WARN",
>>>"INFO",
>>>"DEBUG",
>>>"TRACE"
>>> };
>> 
>> +1
>> 
>> I usually use these levels.
>> 
>> Typical usage:
>> 
>> ERROR:
>>  Print an error message on returning a value other than
>>  OMPI_SUCCESS (and OMPI_ERR_TEMP_OUT_OF_RESOURCE etc.).
>> 
>> WARN:
>>  This does not indicate an error. But users/developers should
>>  be aware on debugging/tuning. For example, network-level
>>  timeout, hardware queue full, buggy code.
>>  Often used with OMPI_ERR_TEMP_OUT_OF_RESOURCE.
>> 
>> INFO:
>>  Information that may be useful for users and developers.
>>  Not so verbose. Output only on initialization or
>>  object creation etc.
>> 
>> DEBUG:
>>  Information that is useful only for developers.
>>  Not so verbose. Output once per MPI routine call.
>> 
>> TRACE:
>>  Information that is useful only for developers.
>>  Verbose. Output more than once per MPI routine call.
>> 
>> Regards,
>> KAWASHIMA Takahiro
>> 
>>> so what about :
>>> 
>>> static const char* const priorities[] = {
>>>"ERROR",
>>>"WARN",
>>>"INFO",
>>>"DEBUG",
>>>"TRACE"
>>> };
>>> 
>>> and merge debug and trace if there should be only 4
>>> 
>>> Cheers,
>>> 
>>> Gilles
>>> 
>>> 
>>> On Monday, June 8, 2015, Ralph Castain  wrote:
>>> 
 Could we maybe narrow it down some? If we are going to do it, let’s not
 make the mistake of the MCA param system and create so many levels. Nobody
 can figure out the right gradation as it is just too fine grained.
 
 I think Nathan’s proposal is the max that makes sense.
 
 I’d also like to see us apply the same logic to the MCA param system.
 Let’s just define ~4 named levels and get rid of the fine grained 
 numbering.
 
 
 On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet >>> > wrote:
 
 Nathan,
 
 i think it is a good idea to use names vs numeric values for verbosity.
 
 what about using "a la" log4c verbosity names ?
 http://sourceforge.net/projects/log4c/
 
 static const char* const priorities[] = {
"FATAL",
"ALERT",
"CRIT",
"ERROR",
"WARN",
"NOTICE",
"INFO",
"DEBUG",
"TRACE",
"NOTSET",
"UNKNOWN"
 };
 
 Cheers,
 
 Gilles
 
 On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
 
 At the moment we have a loosely enforced standard for verbosity
 values. In general frameworks accept anything in the range 0 - 100 with
 few exceptions. I am thinking about adding an enumerator for verbosities
 that will accept values in this range and certain named constants which
 will match with specific verbosity levels. One possible set: none - 0,
 low - 25, med - 50, high - 75, max - 100. I am open to any set of named
 verbosities.
 
 Thoughts?
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/06/17475.php
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17476.php

Re: [OMPI devel] RFC: standardize verbosity values

[Nathan Hjelm]

Yes.

-Nathan

On Mon, Jun 08, 2015 at 09:17:17AM -0700, Ralph Castain wrote:
> So how is the user going to specify these? -mca oob_base_verbose debug?
> 
> > On Jun 8, 2015, at 9:11 AM, Nathan Hjelm  wrote:
> > 
> > 
> > That would work. The standard verbosity levels could be one of those
> > values but allow any number in the interval [0,100] or any of none,
> > error, warn, info, debug, and trace. The standard levels could be
> > defined as:
> > 
> > enum {
> >MCA_BASE_VERBOSE_NONE  = 0,
> >MCA_BASE_VERBOSE_ERROR = 1,
> >MCA_BASE_VERBOSE_WARN  = 10,
> >MCA_BASE_VERBOSE_INFO  = 20,
> >MCA_BASE_VERBOSE_DEBUG = 40,
> >MCA_BASE_VERBOSE_TRACE = 60,
> >MCA_BASE_VERBOSE_MAX   = 100,
> > };
> > 
> > static mca_base_var_enum_value_t verbose_values[] = {
> >{"none",   MCA_BASE_VERBOSE_NONE},
> >{"error",  MCA_BASE_VERBOSE_ERROR},
> >{"warn",   MCA_BASE_VERBOSE_WARN},
> >{"info",   MCA_BASE_VERBOSE_INFO},
> >{"debug",  MCA_BASE_VERBOSE_DEBUG},
> >{"trace",  MCA_BASE_VERBOSE_TRACE},
> >{NULL, -1}
> > };
> > 
> > -Nathan
> > 
> > On Tue, Jun 09, 2015 at 12:42:05AM +0900, KAWASHIMA Takahiro wrote:
> >>> static const char* const priorities[] = {
> >>>"ERROR",
> >>>"WARN",
> >>>"INFO",
> >>>"DEBUG",
> >>>"TRACE"
> >>> };
> >> 
> >> +1
> >> 
> >> I usually use these levels.
> >> 
> >> Typical usage:
> >> 
> >> ERROR:
> >>  Print an error message on returning a value other than
> >>  OMPI_SUCCESS (and OMPI_ERR_TEMP_OUT_OF_RESOURCE etc.).
> >> 
> >> WARN:
> >>  This does not indicate an error. But users/developers should
> >>  be aware on debugging/tuning. For example, network-level
> >>  timeout, hardware queue full, buggy code.
> >>  Often used with OMPI_ERR_TEMP_OUT_OF_RESOURCE.
> >> 
> >> INFO:
> >>  Information that may be useful for users and developers.
> >>  Not so verbose. Output only on initialization or
> >>  object creation etc.
> >> 
> >> DEBUG:
> >>  Information that is useful only for developers.
> >>  Not so verbose. Output once per MPI routine call.
> >> 
> >> TRACE:
> >>  Information that is useful only for developers.
> >>  Verbose. Output more than once per MPI routine call.
> >> 
> >> Regards,
> >> KAWASHIMA Takahiro
> >> 
> >>> so what about :
> >>> 
> >>> static const char* const priorities[] = {
> >>>"ERROR",
> >>>"WARN",
> >>>"INFO",
> >>>"DEBUG",
> >>>"TRACE"
> >>> };
> >>> 
> >>> and merge debug and trace if there should be only 4
> >>> 
> >>> Cheers,
> >>> 
> >>> Gilles
> >>> 
> >>> 
> >>> On Monday, June 8, 2015, Ralph Castain  wrote:
> >>> 
>  Could we maybe narrow it down some? If we are going to do it, let’s not
>  make the mistake of the MCA param system and create so many levels. 
>  Nobody
>  can figure out the right gradation as it is just too fine grained.
>  
>  I think Nathan’s proposal is the max that makes sense.
>  
>  I’d also like to see us apply the same logic to the MCA param system.
>  Let’s just define ~4 named levels and get rid of the fine grained 
>  numbering.
>  
>  
>  On Jun 8, 2015, at 2:04 AM, Gilles Gouaillardet   > wrote:
>  
>  Nathan,
>  
>  i think it is a good idea to use names vs numeric values for verbosity.
>  
>  what about using "a la" log4c verbosity names ?
>  http://sourceforge.net/projects/log4c/
>  
>  static const char* const priorities[] = {
> "FATAL",
> "ALERT",
> "CRIT",
> "ERROR",
> "WARN",
> "NOTICE",
> "INFO",
> "DEBUG",
> "TRACE",
> "NOTSET",
> "UNKNOWN"
>  };
>  
>  Cheers,
>  
>  Gilles
>  
>  On 5/30/2015 1:32 AM, Nathan Hjelm wrote:
>  
>  At the moment we have a loosely enforced standard for verbosity
>  values. In general frameworks accept anything in the range 0 - 100 with
>  few exceptions. I am thinking about adding an enumerator for verbosities
>  that will accept values in this range and certain named constants which
>  will match with specific verbosity levels. One possible set: none - 0,
>  low - 25, med - 50, high - 75, max - 100. I am open to any set of named
>  verbosities.
>  
>  Thoughts?
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post: 
> >> http://www.open-mpi.org/community/lists/devel/2015/06/17475.php
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post: 
> > http://www.open-mpi.org/community/lists/devel/2015/06/17476.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> h

[OMPI devel] Branch for v2.0.0

[Jeff Squyres (jsquyres)]

Developers --

Per our new release scheme, it's (slightly past) time to branch for v2.0.0.

Howard and I would like to talk about branching tomorrow (9 June 2015) on the 
weekly webex:

- what features are incomplete?
- what bug fixes are coming in immanently?
- what else is needed before v2.0.0?
- how much time will these things take?
- generally: what still needs to be done for v2.0.0?

And then -- assuming all goes well -- actually branch next Tuesday (16 June 
2015) after the weekly webex.

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

Re: [OMPI devel] Branch for v2.0.0

[George Bosilca]

Can we wait until the f2f meeting in 2 weeks ?

  George.


On Mon, Jun 8, 2015 at 1:50 PM, Jeff Squyres (jsquyres) 
wrote:

> Developers --
>
> Per our new release scheme, it's (slightly past) time to branch for v2.0.0.
>
> Howard and I would like to talk about branching tomorrow (9 June 2015) on
> the weekly webex:
>
> - what features are incomplete?
> - what bug fixes are coming in immanently?
> - what else is needed before v2.0.0?
> - how much time will these things take?
> - generally: what still needs to be done for v2.0.0?
>
> And then -- assuming all goes well -- actually branch next Tuesday (16
> June 2015) after the weekly webex.
>
> --
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/06/17479.php
>

Re: [OMPI devel] Branch for v2.0.0

[Jeff Squyres (jsquyres)]

The goal is to branch annually on June 1.  We're already past that -- we let it 
slip because we were in Chicago last week at the MPI Forum.  I.e., that seemed 
like a good reason to let it slip.

Howard and I talked about this on the phone today (i.e., whether we should wait 
until the f2f meeting), and concluded, "No, let's give everyone a week and then 
branch."  I.e., discuss tomorrow, and then branch in a week.

Do you have a good reason to let it slip further?




> On Jun 8, 2015, at 2:39 PM, George Bosilca  wrote:
> 
> Can we wait until the f2f meeting in 2 weeks ?
> 
>   George.
> 
> 
> On Mon, Jun 8, 2015 at 1:50 PM, Jeff Squyres (jsquyres)  
> wrote:
> Developers --
> 
> Per our new release scheme, it's (slightly past) time to branch for v2.0.0.
> 
> Howard and I would like to talk about branching tomorrow (9 June 2015) on the 
> weekly webex:
> 
> - what features are incomplete?
> - what bug fixes are coming in immanently?
> - what else is needed before v2.0.0?
> - how much time will these things take?
> - generally: what still needs to be done for v2.0.0?
> 
> And then -- assuming all goes well -- actually branch next Tuesday (16 June 
> 2015) after the weekly webex.
> 
> --
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17479.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17480.php


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

Re: [OMPI devel] Branch for v2.0.0

[George Bosilca]

My only reason is that if we delay the branch for the face-to-face meeting,
so an extra delay of a mere one week, we could use the extra time to
finalize some of the pending updates (e.g. add_proc).

  George.

On Mon, Jun 8, 2015 at 2:43 PM, Jeff Squyres (jsquyres) 
wrote:

> The goal is to branch annually on June 1.  We're already past that -- we
> let it slip because we were in Chicago last week at the MPI Forum.  I.e.,
> that seemed like a good reason to let it slip.
>
> Howard and I talked about this on the phone today (i.e., whether we should
> wait until the f2f meeting), and concluded, "No, let's give everyone a week
> and then branch."  I.e., discuss tomorrow, and then branch in a week.
>
> Do you have a good reason to let it slip further?
>
>
>
>
> > On Jun 8, 2015, at 2:39 PM, George Bosilca  wrote:
> >
> > Can we wait until the f2f meeting in 2 weeks ?
> >
> >   George.
> >
> >
> > On Mon, Jun 8, 2015 at 1:50 PM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> > Developers --
> >
> > Per our new release scheme, it's (slightly past) time to branch for
> v2.0.0.
> >
> > Howard and I would like to talk about branching tomorrow (9 June 2015)
> on the weekly webex:
> >
> > - what features are incomplete?
> > - what bug fixes are coming in immanently?
> > - what else is needed before v2.0.0?
> > - how much time will these things take?
> > - generally: what still needs to be done for v2.0.0?
> >
> > And then -- assuming all goes well -- actually branch next Tuesday (16
> June 2015) after the weekly webex.
> >
> > --
> > 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
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/06/17479.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/06/17480.php
>
>
> --
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/06/17481.php
>

Re: [OMPI devel] Branch for v2.0.0

[Edgar Gabriel]

I am halfway through the infrastructure changes required for the 
non-blocking collective I/O operations. It will take me probably 2 more 
days of coding to finish what I wanted to get done before the branch, 
but unfortunately I can not guarantee that I will get to it this week. 
Since it is very well isolated area in the code base, I think however 
that a pull request from master to the 2.0 branch will probably not be 
dramatic.


Edgar

On 6/8/2015 7:50 PM, Jeff Squyres (jsquyres) wrote:

Developers --

Per our new release scheme, it's (slightly past) time to branch for v2.0.0.

Howard and I would like to talk about branching tomorrow (9 June 2015) on the 
weekly webex:

- what features are incomplete?
- what bug fixes are coming in immanently?
- what else is needed before v2.0.0?
- how much time will these things take?
- generally: what still needs to be done for v2.0.0?

And then -- assuming all goes well -- actually branch next Tuesday (16 June 
2015) after the weekly webex.



--
Edgar Gabriel
Associate Professor
Parallel Software Technologies Lab  http://pstl.cs.uh.edu
Department of Computer Science  University of Houston
Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
--

Re: [OMPI devel] Branch for v2.0.0

[Jeff Squyres (jsquyres)]

In a perfect world, branching = feature complete.  But I doubt that will be the 
case here.

Let's talk about it on the call tomorrow and scope what 2.0 things are still 
being worked on.


> On Jun 8, 2015, at 4:07 PM, George Bosilca  wrote:
> 
> My only reason is that if we delay the branch for the face-to-face meeting, 
> so an extra delay of a mere one week, we could use the extra time to finalize 
> some of the pending updates (e.g. add_proc).
> 
>   George.
> 
> On Mon, Jun 8, 2015 at 2:43 PM, Jeff Squyres (jsquyres)  
> wrote:
> The goal is to branch annually on June 1.  We're already past that -- we let 
> it slip because we were in Chicago last week at the MPI Forum.  I.e., that 
> seemed like a good reason to let it slip.
> 
> Howard and I talked about this on the phone today (i.e., whether we should 
> wait until the f2f meeting), and concluded, "No, let's give everyone a week 
> and then branch."  I.e., discuss tomorrow, and then branch in a week.
> 
> Do you have a good reason to let it slip further?
> 
> 
> 
> 
> > On Jun 8, 2015, at 2:39 PM, George Bosilca  wrote:
> >
> > Can we wait until the f2f meeting in 2 weeks ?
> >
> >   George.
> >
> >
> > On Mon, Jun 8, 2015 at 1:50 PM, Jeff Squyres (jsquyres) 
> >  wrote:
> > Developers --
> >
> > Per our new release scheme, it's (slightly past) time to branch for v2.0.0.
> >
> > Howard and I would like to talk about branching tomorrow (9 June 2015) on 
> > the weekly webex:
> >
> > - what features are incomplete?
> > - what bug fixes are coming in immanently?
> > - what else is needed before v2.0.0?
> > - how much time will these things take?
> > - generally: what still needs to be done for v2.0.0?
> >
> > And then -- assuming all goes well -- actually branch next Tuesday (16 June 
> > 2015) after the weekly webex.
> >
> > --
> > 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
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post: 
> > http://www.open-mpi.org/community/lists/devel/2015/06/17479.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post: 
> > http://www.open-mpi.org/community/lists/devel/2015/06/17480.php
> 
> 
> --
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17481.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17482.php


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

Re: [OMPI devel] Branch for v2.0.0

[Jeff Squyres (jsquyres)]

Got it; thanks. 

Sent from my phone. No type good. 

> On Jun 8, 2015, at 4:14 PM, Edgar Gabriel  wrote:
> 
> I am halfway through the infrastructure changes required for the non-blocking 
> collective I/O operations. It will take me probably 2 more days of coding to 
> finish what I wanted to get done before the branch, but unfortunately I can 
> not guarantee that I will get to it this week. Since it is very well isolated 
> area in the code base, I think however that a pull request from master to the 
> 2.0 branch will probably not be dramatic.
> 
> Edgar
> 
>> On 6/8/2015 7:50 PM, Jeff Squyres (jsquyres) wrote:
>> Developers --
>> 
>> Per our new release scheme, it's (slightly past) time to branch for v2.0.0.
>> 
>> Howard and I would like to talk about branching tomorrow (9 June 2015) on 
>> the weekly webex:
>> 
>> - what features are incomplete?
>> - what bug fixes are coming in immanently?
>> - what else is needed before v2.0.0?
>> - how much time will these things take?
>> - generally: what still needs to be done for v2.0.0?
>> 
>> And then -- assuming all goes well -- actually branch next Tuesday (16 June 
>> 2015) after the weekly webex.
> 
> -- 
> Edgar Gabriel
> Associate Professor
> Parallel Software Technologies Lab  http://pstl.cs.uh.edu
> Department of Computer Science  University of Houston
> Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
> Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
> --
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/06/17483.php