Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

[Paul Hargrove]

Jeff,

Using calloc() only subject to --with-valgrind sounds good to me.
If I'd known such a option exists, I'd not have suggested the MCA param
idea.

-Paul

On Fri, Oct 3, 2014 at 3:33 PM, Jeff Squyres (jsquyres) 
wrote:

> How about a compromise -- how about enabling calloc() when --with-valgrind
> is specified on the command line?
>
> I.e., don't tie it to debug builds, but to valgrind-enabled builds?
>
>
> On Oct 3, 2014, at 6:11 PM, Paul Hargrove  wrote:
>
> > I agree with George that zeroing memory only in the debug builds could
> hide bugs, and thus would want to see the debug and non-debug builds have
> the same behavior (both malloc or both calloc).  So, I also agree this
> looks initially like a hard choice.
> >
> > What about using malloc() in non-debug builds and having a MCA param
> control malloc-vs-calloc in a debug build (with malloc being the default)?
> The param name could be something with "valgrind" in it to allow it to
> control any other "paranoid code" that may be introduced just to silence
> valgrind warnings.
> >
> > -Paul
> >
> > On Fri, Oct 3, 2014 at 3:02 PM, George Bosilca 
> wrote:
> > It's a tough call. This proposal will create significant differences
> between the debug and fast builds. As the entire objects will be set to
> zero this might reduce bugs in the debug build, bugs that will be horribly
> difficult to track in any non-debug builds. Moreover, if the structures are
> carefully accessed in our code, adding such a disruptive initialization
> just to prevent valgrind from reporting false-positive about uninitialized
> reads in memcpy is too costly as a solution (I am also conscient that it
> will be almost impossible to write a valgrind suppression rule for the
> specific case you mention).
> >
> > Some parts of the code have (or at least had) some level of cleanness
> for the gaps in the structures. The solution was to minimally zero-fy the
> gaps, maintaining the same behavior between debug and non-debug builds.
> However, in order to do this one need to know the layout of the structure,
> so this is not a completely generic solution...
> >
> >   George.
> >
> >
> > On Oct 3, 2014, at 16:54 , Jeff Squyres (jsquyres) 
> wrote:
> >
> > > WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only
> in debug builds?)
> > >
> > > WHY: Drastically reduces valgrind output
> > >
> > > WHERE: see
> https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467
> > >
> > > TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)
> > >
> > > MORE DETAIL:
> > >
> > > I was debugging some code today and came across a bunch of places
> where we write structs down various IPC mechanisms, and the structs contain
> holes.  In most places, the performance doesn't matter / the readability of
> struct members is more important, so we haven't re-ordered the structs to
> remove holes.  But consequently, those holes end up uninitialized, and
> therefore memcpy()ing or write()ing instances of these structs causes
> valgrind to emit warnings.
> > >
> > > The patch below eliminates most (all?) of these valgrind warnings --
> in debug builds, it changes the malloc() inside OBJ_NEW to a calloc().
> > >
> > > Upon a little more thought, however, I wonder if we use OBJ_NEW in any
> fast code paths (other than in bulk, such as when we need to grow a free
> list).  Specifically: would it be terrible to *always* calloc -- not just
> for debug builds?
> > >
> > > -
> > > diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h
> > > index 7012bac..585f13e 100644
> > > --- a/opal/class/opal_object.h
> > > +++ b/opal/class/opal_object.h
> > > @@ -464,7 +464,11 @@ static inline opal_object_t
> *opal_obj_new(opal_class_t * cl
> > > opal_object_t *object;
> > > assert(cls->cls_sizeof >= sizeof(opal_object_t));
> > >
> > > +#if OPAL_ENABLE_DEBUG
> > > +object = (opal_object_t *) calloc(1, cls->cls_sizeof);
> > > +#else
> > > object = (opal_object_t *) malloc(cls->cls_sizeof);
> > > +#endif
> > > if (0 == cls->cls_initialized) {
> > > opal_class_initialize(cls);
> > > }
> > > -
> > >
> > > --
> > > 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/2014/10/16001.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/2014/10/16004.php
> >
> >
> >
> > --
> > Paul H. Hargrove  phhargr...@lbl.gov
> > Future 

Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

[Howard]

Hi Jeff,

I'd be okay with this as long as there would be a config option to revert
back to using malloc rather than calloc.

Howard

On 10/3/14 2:54 PM, Jeff Squyres (jsquyres) wrote:

WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in debug 
builds?)

WHY: Drastically reduces valgrind output

WHERE: see 
https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467

TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)

MORE DETAIL:

I was debugging some code today and came across a bunch of places where we 
write structs down various IPC mechanisms, and the structs contain holes.  In 
most places, the performance doesn't matter / the readability of struct members 
is more important, so we haven't re-ordered the structs to remove holes.  But 
consequently, those holes end up uninitialized, and therefore memcpy()ing or 
write()ing instances of these structs causes valgrind to emit warnings.

The patch below eliminates most (all?) of these valgrind warnings -- in debug 
builds, it changes the malloc() inside OBJ_NEW to a calloc().

Upon a little more thought, however, I wonder if we use OBJ_NEW in any fast 
code paths (other than in bulk, such as when we need to grow a free list).  
Specifically: would it be terrible to *always* calloc -- not just for debug 
builds?

-
diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h
index 7012bac..585f13e 100644
--- a/opal/class/opal_object.h
+++ b/opal/class/opal_object.h
@@ -464,7 +464,11 @@ static inline opal_object_t *opal_obj_new(opal_class_t * cl
  opal_object_t *object;
  assert(cls->cls_sizeof >= sizeof(opal_object_t));
  
+#if OPAL_ENABLE_DEBUG

+object = (opal_object_t *) calloc(1, cls->cls_sizeof);
+#else
  object = (opal_object_t *) malloc(cls->cls_sizeof);
+#endif
  if (0 == cls->cls_initialized) {
  opal_class_initialize(cls);
  }
-

Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

[Jeff Squyres (jsquyres)]

How about a compromise -- how about enabling calloc() when --with-valgrind is 
specified on the command line?

I.e., don't tie it to debug builds, but to valgrind-enabled builds?


On Oct 3, 2014, at 6:11 PM, Paul Hargrove  wrote:

> I agree with George that zeroing memory only in the debug builds could hide 
> bugs, and thus would want to see the debug and non-debug builds have the same 
> behavior (both malloc or both calloc).  So, I also agree this looks initially 
> like a hard choice.
> 
> What about using malloc() in non-debug builds and having a MCA param control 
> malloc-vs-calloc in a debug build (with malloc being the default)?  The param 
> name could be something with "valgrind" in it to allow it to control any 
> other "paranoid code" that may be introduced just to silence valgrind 
> warnings.
> 
> -Paul
> 
> On Fri, Oct 3, 2014 at 3:02 PM, George Bosilca  wrote:
> It’s a tough call. This proposal will create significant differences between 
> the debug and fast builds. As the entire objects will be set to zero this 
> might reduce bugs in the debug build, bugs that will be horribly difficult to 
> track in any non-debug builds. Moreover, if the structures are carefully 
> accessed in our code, adding such a disruptive initialization just to prevent 
> valgrind from reporting false-positive about uninitialized reads in memcpy is 
> too costly as a solution (I am also conscient that it will be almost 
> impossible to write a valgrind suppression rule for the specific case you 
> mention).
> 
> Some parts of the code have (or at least had) some level of cleanness for the 
> gaps in the structures. The solution was to minimally zero-fy the gaps, 
> maintaining the same behavior between debug and non-debug builds. However, in 
> order to do this one need to know the layout of the structure, so this is not 
> a completely generic solution…
> 
>   George.
> 
> 
> On Oct 3, 2014, at 16:54 , Jeff Squyres (jsquyres)  wrote:
> 
> > WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in 
> > debug builds?)
> >
> > WHY: Drastically reduces valgrind output
> >
> > WHERE: see 
> > https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467
> >
> > TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)
> >
> > MORE DETAIL:
> >
> > I was debugging some code today and came across a bunch of places where we 
> > write structs down various IPC mechanisms, and the structs contain holes.  
> > In most places, the performance doesn't matter / the readability of struct 
> > members is more important, so we haven't re-ordered the structs to remove 
> > holes.  But consequently, those holes end up uninitialized, and therefore 
> > memcpy()ing or write()ing instances of these structs causes valgrind to 
> > emit warnings.
> >
> > The patch below eliminates most (all?) of these valgrind warnings -- in 
> > debug builds, it changes the malloc() inside OBJ_NEW to a calloc().
> >
> > Upon a little more thought, however, I wonder if we use OBJ_NEW in any fast 
> > code paths (other than in bulk, such as when we need to grow a free list).  
> > Specifically: would it be terrible to *always* calloc -- not just for debug 
> > builds?
> >
> > -
> > diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h
> > index 7012bac..585f13e 100644
> > --- a/opal/class/opal_object.h
> > +++ b/opal/class/opal_object.h
> > @@ -464,7 +464,11 @@ static inline opal_object_t *opal_obj_new(opal_class_t 
> > * cl
> > opal_object_t *object;
> > assert(cls->cls_sizeof >= sizeof(opal_object_t));
> >
> > +#if OPAL_ENABLE_DEBUG
> > +object = (opal_object_t *) calloc(1, cls->cls_sizeof);
> > +#else
> > object = (opal_object_t *) malloc(cls->cls_sizeof);
> > +#endif
> > if (0 == cls->cls_initialized) {
> > opal_class_initialize(cls);
> > }
> > -
> >
> > --
> > 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/2014/10/16001.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/2014/10/16004.php
> 
> 
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> 

Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

[Paul Hargrove]

I agree with George that zeroing memory only in the debug builds could hide
bugs, and thus would want to see the debug and non-debug builds have the
same behavior (both malloc or both calloc).  So, I also agree this looks
initially like a hard choice.

What about using malloc() in non-debug builds and having a MCA param
control malloc-vs-calloc in a debug build (with malloc being the default)?
The param name could be something with "valgrind" in it to allow it to
control any other "paranoid code" that may be introduced just to silence
valgrind warnings.

-Paul

On Fri, Oct 3, 2014 at 3:02 PM, George Bosilca  wrote:

> It's a tough call. This proposal will create significant differences
> between the debug and fast builds. As the entire objects will be set to
> zero this might reduce bugs in the debug build, bugs that will be horribly
> difficult to track in any non-debug builds. Moreover, if the structures are
> carefully accessed in our code, adding such a disruptive initialization
> just to prevent valgrind from reporting false-positive about uninitialized
> reads in memcpy is too costly as a solution (I am also conscient that it
> will be almost impossible to write a valgrind suppression rule for the
> specific case you mention).
>
> Some parts of the code have (or at least had) some level of cleanness for
> the gaps in the structures. The solution was to minimally zero-fy the gaps,
> maintaining the same behavior between debug and non-debug builds. However,
> in order to do this one need to know the layout of the structure, so this
> is not a completely generic solution...
>
>   George.
>
>
> On Oct 3, 2014, at 16:54 , Jeff Squyres (jsquyres) 
> wrote:
>
> > WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in
> debug builds?)
> >
> > WHY: Drastically reduces valgrind output
> >
> > WHERE: see
> https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467
> >
> > TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)
> >
> > MORE DETAIL:
> >
> > I was debugging some code today and came across a bunch of places where
> we write structs down various IPC mechanisms, and the structs contain
> holes.  In most places, the performance doesn't matter / the readability of
> struct members is more important, so we haven't re-ordered the structs to
> remove holes.  But consequently, those holes end up uninitialized, and
> therefore memcpy()ing or write()ing instances of these structs causes
> valgrind to emit warnings.
> >
> > The patch below eliminates most (all?) of these valgrind warnings -- in
> debug builds, it changes the malloc() inside OBJ_NEW to a calloc().
> >
> > Upon a little more thought, however, I wonder if we use OBJ_NEW in any
> fast code paths (other than in bulk, such as when we need to grow a free
> list).  Specifically: would it be terrible to *always* calloc -- not just
> for debug builds?
> >
> > -
> > diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h
> > index 7012bac..585f13e 100644
> > --- a/opal/class/opal_object.h
> > +++ b/opal/class/opal_object.h
> > @@ -464,7 +464,11 @@ static inline opal_object_t
> *opal_obj_new(opal_class_t * cl
> > opal_object_t *object;
> > assert(cls->cls_sizeof >= sizeof(opal_object_t));
> >
> > +#if OPAL_ENABLE_DEBUG
> > +object = (opal_object_t *) calloc(1, cls->cls_sizeof);
> > +#else
> > object = (opal_object_t *) malloc(cls->cls_sizeof);
> > +#endif
> > if (0 == cls->cls_initialized) {
> > opal_class_initialize(cls);
> > }
> > -
> >
> > --
> > 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/2014/10/16001.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/2014/10/16004.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

[George Bosilca]

It’s a tough call. This proposal will create significant differences between 
the debug and fast builds. As the entire objects will be set to zero this might 
reduce bugs in the debug build, bugs that will be horribly difficult to track 
in any non-debug builds. Moreover, if the structures are carefully accessed in 
our code, adding such a disruptive initialization just to prevent valgrind from 
reporting false-positive about uninitialized reads in memcpy is too costly as a 
solution (I am also conscient that it will be almost impossible to write a 
valgrind suppression rule for the specific case you mention).

Some parts of the code have (or at least had) some level of cleanness for the 
gaps in the structures. The solution was to minimally zero-fy the gaps, 
maintaining the same behavior between debug and non-debug builds. However, in 
order to do this one need to know the layout of the structure, so this is not a 
completely generic solution…

  George.


On Oct 3, 2014, at 16:54 , Jeff Squyres (jsquyres)  wrote:

> WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in 
> debug builds?)
> 
> WHY: Drastically reduces valgrind output
> 
> WHERE: see 
> https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467
> 
> TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)
> 
> MORE DETAIL:
> 
> I was debugging some code today and came across a bunch of places where we 
> write structs down various IPC mechanisms, and the structs contain holes.  In 
> most places, the performance doesn't matter / the readability of struct 
> members is more important, so we haven't re-ordered the structs to remove 
> holes.  But consequently, those holes end up uninitialized, and therefore 
> memcpy()ing or write()ing instances of these structs causes valgrind to emit 
> warnings.
> 
> The patch below eliminates most (all?) of these valgrind warnings -- in debug 
> builds, it changes the malloc() inside OBJ_NEW to a calloc().
> 
> Upon a little more thought, however, I wonder if we use OBJ_NEW in any fast 
> code paths (other than in bulk, such as when we need to grow a free list).  
> Specifically: would it be terrible to *always* calloc -- not just for debug 
> builds?
> 
> -
> diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h
> index 7012bac..585f13e 100644
> --- a/opal/class/opal_object.h
> +++ b/opal/class/opal_object.h
> @@ -464,7 +464,11 @@ static inline opal_object_t *opal_obj_new(opal_class_t * 
> cl
> opal_object_t *object;
> assert(cls->cls_sizeof >= sizeof(opal_object_t));
> 
> +#if OPAL_ENABLE_DEBUG
> +object = (opal_object_t *) calloc(1, cls->cls_sizeof);
> +#else
> object = (opal_object_t *) malloc(cls->cls_sizeof);
> +#endif
> if (0 == cls->cls_initialized) {
> opal_class_initialize(cls);
> }
> -
> 
> -- 
> 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/2014/10/16001.php

Re: [OMPI devel] opal components subject to removal for 1.9 release

[George Bosilca]

On Oct 3, 2014, at 17:06 , Howard  wrote:

> Hello OMPI folks,
> 
> As part of the code cleanup for release 1.9/2.0, there are several
> opal components that are on the radar for possible removal.
> 
> These include:
> 
> mca/btl/template (not clear anyone is maintaining this)

This component requires minimal maintenance, as it is a template for BTL 
development. A quick look at the last commits show that people are indeed doing 
updates on a regular basis.

  George.

> mca/common/ofacm
> mca/crs/dmtcp
> mca/if/solaris_ipv6 (the maintainer is nominally Oracle)
> mca/if/windows
> mca/installdirs/windows
> mca/memory/malloc_solaris (Oracle)
> timer/catamount (this is about to go, SNL verified not using)
> timer/windows
> 
> The tables at the bottom of the following wiki page provide more
> info - https://github.com/open-mpi/ompi/wiki/Releasev19
> 
> If you think any of these components need to be maintained
> going forward, please speak up.
> 
> ORTE and OMPI components will be discussed at next week's
> devel meeting.
> 
> Thanks,
> 
> Howard
> 
> 
> 
> 
> 
> ___
> 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/2014/10/16002.php

[OMPI devel] RFC: calloc instead of malloc in opal_obj_new()

[Jeff Squyres (jsquyres)]

WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in debug 
builds?)

WHY: Drastically reduces valgrind output

WHERE: see 
https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467

TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)

MORE DETAIL:

I was debugging some code today and came across a bunch of places where we 
write structs down various IPC mechanisms, and the structs contain holes.  In 
most places, the performance doesn't matter / the readability of struct members 
is more important, so we haven't re-ordered the structs to remove holes.  But 
consequently, those holes end up uninitialized, and therefore memcpy()ing or 
write()ing instances of these structs causes valgrind to emit warnings.

The patch below eliminates most (all?) of these valgrind warnings -- in debug 
builds, it changes the malloc() inside OBJ_NEW to a calloc().

Upon a little more thought, however, I wonder if we use OBJ_NEW in any fast 
code paths (other than in bulk, such as when we need to grow a free list).  
Specifically: would it be terrible to *always* calloc -- not just for debug 
builds?

-
diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h
index 7012bac..585f13e 100644
--- a/opal/class/opal_object.h
+++ b/opal/class/opal_object.h
@@ -464,7 +464,11 @@ static inline opal_object_t *opal_obj_new(opal_class_t * cl
 opal_object_t *object;
 assert(cls->cls_sizeof >= sizeof(opal_object_t));
 
+#if OPAL_ENABLE_DEBUG
+object = (opal_object_t *) calloc(1, cls->cls_sizeof);
+#else
 object = (opal_object_t *) malloc(cls->cls_sizeof);
+#endif
 if (0 == cls->cls_initialized) {
 opal_class_initialize(cls);
 }
-

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

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Bert Wesarg]

On 10/03/2014 01:23 PM, Jeff Squyres (jsquyres) wrote:

On Oct 3, 2014, at 7:11 AM, Gilles Gouaillardet  
wrote:


I think you're suggesting "git log | grep SVN rxxx", right?


i do not think this returns the git commit id, does it ?

what i had in mind is :
git log master
and then /r
and manually retrieve the git commit id a few lines above


Ah, yes -- good point.


Better let git do the grep:

git log --grep=r

Bert





--
Dipl.-Inf. Bert Wesarg
wiss. Mitarbeiter

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH)
01062 Dresden
Tel.: +49 (351) 463-42451
Fax: +49 (351) 463-37773
E-Mail: bert.wes...@tu-dresden.de



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OMPI devel] OMPI devel] OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Gilles Gouaillardet]

will do !

Gilles

"Jeff Squyres (jsquyres)"  wrote:
>That's a possibility.  IU could probably host this for us.
>
>Would you mind looking into how hard this would be?
>
>
>On Oct 3, 2014, at 8:41 AM, Gilles Gouaillardet 
> wrote:
>
>> Jeff,
>> 
>> What about a bot using github's rich REST api that parses PR and 
>> automatically sets label/milestone/assignee when a keyword is found ?
>> 
>> for example :
>> PR:milestone=v1.8.4:assignee=jsquyres:label=bug
>> or
>> #milestone=v1.8.4 #assignee=@jsquyres #label=bug
>> 
>> i can investigate this way if needed
>> 
>> Cheers,
>> 
>> Gilles
>> 
>> "Jeff Squyres (jsquyres)"  wrote:
>>> Gah.
>>> 
>>> I just did some experimentation and confirmed this behavior:
>>> 
>>> 1. If you do not belong to a repo, you can file issues/pull requests and 
>>> comment on them.
>>> 
>>> 2. If you have *read* access to a repo, you can do everything from #1, but 
>>> you're also eligible for @mention auto-complete, and issues/pull requests 
>>> can be assigned to you.
>>> 
>>> 3. If you have *write* access to a repo, you can do everything from #2, but 
>>> you can also set labels, milestones, and assignees.
>>> 
>>> All the OMPI devs have *read* access to ompi-release, meaning you can 
>>> create/comment on issues, but not set labels/milestones/assignees.
>>> 
>>> I did not expect this behavior.  Grumble.  Will have to think about it a 
>>> bit...
>>> 
>>> 
>>> 
>>> 
>>> On Oct 3, 2014, at 7:07 AM, Gilles Gouaillardet 
>>>  wrote:
>>> 
 Jeff,
 
 my point is that label, milestone and assignee are *not* clickable for me 
 (see attached snapshot, "settings" icons are missing
 
 Cheers,
 
 Gilles
 
 On Fri, Oct 3, 2014 at 7:36 PM, Jeff Squyres (jsquyres) 
  wrote:
 You can only assign a label and milestone, and assign the PR to someone, 
 *after* you create the PR (same with creating issues).
 
 See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:
 
 
 
 
 
 
 On Oct 2, 2014, at 11:37 PM, Gilles Gouaillardet 
  wrote:
 
 
> Jeff,
> 
> i could not find how to apply a label to a PR via the web interface (and
> i am not sure i can even do that since authority might be required)
> 
> any idea (maybe a special keyword in the comment ...) ?
> 
> Cheers,
> 
> Gilles
> 
> On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
>> On Oct 2, 2014, at 12:47 PM, Ralph Castain  wrote:
>> 
>>> How are they going to review it, given they don't have authority to do 
>>> anything on that branch? Can they still comment? Can they reassign them 
>>> when done?
>> Yes, they can comment.
>> 
>> The idea was that they would apply the "reviewed" label when they have 
>> reviewed it successfully.  These "reviewed" labels will then be easily 
>> viewable in the PR listing by the RM/GK to know which ones are ready.
>> 
> 
> ___
> 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/2014/10/15988.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/2014/10/15990.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/2014/10/15992.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/2014/10/15995.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/2014/10/15996.php
>
>
>-- 
>Jeff Squyres
>jsquy...@cisco.com
>For corporate legal information go to: 
>http://www.cisco.com/web/about/doing_business/legal/cri/
>

[OMPI devel] Update your MTT config: nightly master tarballs

[Jeff Squyres (jsquyres)]

Note that the main development area is now called "master", not "trunk".

So you need to update your MTT INI file to point to where the new master 
nightly snapshot tarballs will live.  It used to be:

ompi_snapshot_url = http://www.open-mpi.org/nightly/trunk

Now it needs to be:

ompi_snapshot_url = http://www.open-mpi.org/nightly/master

The nightly didn't work properly last night; I'm fixing it...

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

Re: [OMPI devel] OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Jeff Squyres (jsquyres)]

That's a possibility.  IU could probably host this for us.

Would you mind looking into how hard this would be?


On Oct 3, 2014, at 8:41 AM, Gilles Gouaillardet  
wrote:

> Jeff,
> 
> What about a bot using github's rich REST api that parses PR and 
> automatically sets label/milestone/assignee when a keyword is found ?
> 
> for example :
> PR:milestone=v1.8.4:assignee=jsquyres:label=bug
> or
> #milestone=v1.8.4 #assignee=@jsquyres #label=bug
> 
> i can investigate this way if needed
> 
> Cheers,
> 
> Gilles
> 
> "Jeff Squyres (jsquyres)"  wrote:
>> Gah.
>> 
>> I just did some experimentation and confirmed this behavior:
>> 
>> 1. If you do not belong to a repo, you can file issues/pull requests and 
>> comment on them.
>> 
>> 2. If you have *read* access to a repo, you can do everything from #1, but 
>> you're also eligible for @mention auto-complete, and issues/pull requests 
>> can be assigned to you.
>> 
>> 3. If you have *write* access to a repo, you can do everything from #2, but 
>> you can also set labels, milestones, and assignees.
>> 
>> All the OMPI devs have *read* access to ompi-release, meaning you can 
>> create/comment on issues, but not set labels/milestones/assignees.
>> 
>> I did not expect this behavior.  Grumble.  Will have to think about it a 
>> bit...
>> 
>> 
>> 
>> 
>> On Oct 3, 2014, at 7:07 AM, Gilles Gouaillardet 
>>  wrote:
>> 
>>> Jeff,
>>> 
>>> my point is that label, milestone and assignee are *not* clickable for me 
>>> (see attached snapshot, "settings" icons are missing
>>> 
>>> Cheers,
>>> 
>>> Gilles
>>> 
>>> On Fri, Oct 3, 2014 at 7:36 PM, Jeff Squyres (jsquyres) 
>>>  wrote:
>>> You can only assign a label and milestone, and assign the PR to someone, 
>>> *after* you create the PR (same with creating issues).
>>> 
>>> See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Oct 2, 2014, at 11:37 PM, Gilles Gouaillardet 
>>>  wrote:
>>> 
>>> 
 Jeff,
 
 i could not find how to apply a label to a PR via the web interface (and
 i am not sure i can even do that since authority might be required)
 
 any idea (maybe a special keyword in the comment ...) ?
 
 Cheers,
 
 Gilles
 
 On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 12:47 PM, Ralph Castain  wrote:
> 
>> How are they going to review it, given they don't have authority to do 
>> anything on that branch? Can they still comment? Can they reassign them 
>> when done?
> Yes, they can comment.
> 
> The idea was that they would apply the "reviewed" label when they have 
> reviewed it successfully.  These "reviewed" labels will then be easily 
> viewable in the PR listing by the RM/GK to know which ones are ready.
> 
 
 ___
 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/2014/10/15988.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/2014/10/15990.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/2014/10/15992.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/2014/10/15995.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/2014/10/15996.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] OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Gilles Gouaillardet]

Jeff,

What about a bot using github's rich REST api that parses PR and automatically 
sets label/milestone/assignee when a keyword is found ?

for example :
PR:milestone=v1.8.4:assignee=jsquyres:label=bug
or
#milestone=v1.8.4 #assignee=@jsquyres #label=bug

i can investigate this way if needed

Cheers,

Gilles

"Jeff Squyres (jsquyres)"  wrote:
>Gah.
>
>I just did some experimentation and confirmed this behavior:
>
>1. If you do not belong to a repo, you can file issues/pull requests and 
>comment on them.
>
>2. If you have *read* access to a repo, you can do everything from #1, but 
>you're also eligible for @mention auto-complete, and issues/pull requests can 
>be assigned to you.
>
>3. If you have *write* access to a repo, you can do everything from #2, but 
>you can also set labels, milestones, and assignees.
>
>All the OMPI devs have *read* access to ompi-release, meaning you can 
>create/comment on issues, but not set labels/milestones/assignees.
>
>I did not expect this behavior.  Grumble.  Will have to think about it a bit...
>
>
>
>
>On Oct 3, 2014, at 7:07 AM, Gilles Gouaillardet 
> wrote:
>
>> Jeff,
>> 
>> my point is that label, milestone and assignee are *not* clickable for me 
>> (see attached snapshot, "settings" icons are missing
>> 
>> Cheers,
>> 
>> Gilles
>> 
>> On Fri, Oct 3, 2014 at 7:36 PM, Jeff Squyres (jsquyres)  
>> wrote:
>> You can only assign a label and milestone, and assign the PR to someone, 
>> *after* you create the PR (same with creating issues).
>> 
>> See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:
>> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 2, 2014, at 11:37 PM, Gilles Gouaillardet 
>>  wrote:
>> 
>> 
>>> Jeff,
>>> 
>>> i could not find how to apply a label to a PR via the web interface (and
>>> i am not sure i can even do that since authority might be required)
>>> 
>>> any idea (maybe a special keyword in the comment ...) ?
>>> 
>>> Cheers,
>>> 
>>> Gilles
>>> 
>>> On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
 On Oct 2, 2014, at 12:47 PM, Ralph Castain  wrote:
 
> How are they going to review it, given they don't have authority to do 
> anything on that branch? Can they still comment? Can they reassign them 
> when done?
 Yes, they can comment.
 
 The idea was that they would apply the "reviewed" label when they have 
 reviewed it successfully.  These "reviewed" labels will then be easily 
 viewable in the PR listing by the RM/GK to know which ones are ready.
 
>>> 
>>> ___
>>> 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/2014/10/15988.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/2014/10/15990.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/2014/10/15992.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/2014/10/15995.php

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Jeff Squyres (jsquyres)]

Gah.

I just did some experimentation and confirmed this behavior:

1. If you do not belong to a repo, you can file issues/pull requests and 
comment on them.

2. If you have *read* access to a repo, you can do everything from #1, but 
you're also eligible for @mention auto-complete, and issues/pull requests can 
be assigned to you.

3. If you have *write* access to a repo, you can do everything from #2, but you 
can also set labels, milestones, and assignees.

All the OMPI devs have *read* access to ompi-release, meaning you can 
create/comment on issues, but not set labels/milestones/assignees.

I did not expect this behavior.  Grumble.  Will have to think about it a bit...




On Oct 3, 2014, at 7:07 AM, Gilles Gouaillardet  
wrote:

> Jeff,
> 
> my point is that label, milestone and assignee are *not* clickable for me 
> (see attached snapshot, "settings" icons are missing
> 
> Cheers,
> 
> Gilles
> 
> On Fri, Oct 3, 2014 at 7:36 PM, Jeff Squyres (jsquyres)  
> wrote:
> You can only assign a label and milestone, and assign the PR to someone, 
> *after* you create the PR (same with creating issues).
> 
> See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:
> 
> 
> 
> 
> 
> 
> On Oct 2, 2014, at 11:37 PM, Gilles Gouaillardet 
>  wrote:
> 
> 
>> Jeff,
>> 
>> i could not find how to apply a label to a PR via the web interface (and
>> i am not sure i can even do that since authority might be required)
>> 
>> any idea (maybe a special keyword in the comment ...) ?
>> 
>> Cheers,
>> 
>> Gilles
>> 
>> On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
>>> On Oct 2, 2014, at 12:47 PM, Ralph Castain  wrote:
>>> 
 How are they going to review it, given they don't have authority to do 
 anything on that branch? Can they still comment? Can they reassign them 
 when done?
>>> Yes, they can comment.
>>> 
>>> The idea was that they would apply the "reviewed" label when they have 
>>> reviewed it successfully.  These "reviewed" labels will then be easily 
>>> viewable in the PR listing by the RM/GK to know which ones are ready.
>>> 
>> 
>> ___
>> 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/2014/10/15988.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/2014/10/15990.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/2014/10/15992.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] OMPI@GitHub: (Mostly) Open for business

[Jeff Squyres (jsquyres)]

On Oct 3, 2014, at 7:11 AM, Gilles Gouaillardet  
wrote:

> > I think you're suggesting "git log | grep SVN rxxx", right?
> 
> i do not think this returns the git commit id, does it ?
> 
> what i had in mind is :
> git log master
> and then /r
> and manually retrieve the git commit id a few lines above

Ah, yes -- good point.

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

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Gilles Gouaillardet]

On Fri, Oct 3, 2014 at 7:29 PM, Jeff Squyres (jsquyres) 
wrote:

> On Oct 2, 2014, at 11:33 PM, Gilles Gouaillardet <
> gilles.gouaillar...@iferc.org> wrote:
>
> > the most painful part is probably to manually retrieve the git commit id
> > of a given svn commit id
> >
> > git log master, and then search r
> > /* each commit log has a line like :
> > This commit was SVN rx
> > */
>
> I think you're suggesting "git log | grep SVN rxxx", right?
>
> i do not think this returns the git commit id, does it ?

what i had in mind is :
git log master
and then /r
and manually retrieve the git commit id a few lines above

this is very likely achievable with an awk oneliner, but i do not know how
...

Cheers,

Gilles

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Gilles Gouaillardet]

Jeff,

my point is that label, milestone and assignee are *not* clickable for me
(see attached snapshot, "settings" icons are missing

Cheers,

Gilles

On Fri, Oct 3, 2014 at 7:36 PM, Jeff Squyres (jsquyres) 
wrote:

>  You can only assign a label and milestone, and assign the PR to someone,
> *after* you create the PR (same with creating issues).
>
>  See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:
>
>
>
>
>
>
>  On Oct 2, 2014, at 11:37 PM, Gilles Gouaillardet <
> gilles.gouaillar...@iferc.org> wrote:
>
>
> Jeff,
>
> i could not find how to apply a label to a PR via the web interface (and
> i am not sure i can even do that since authority might be required)
>
> any idea (maybe a special keyword in the comment ...) ?
>
> Cheers,
>
> Gilles
>
> On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
>
> On Oct 2, 2014, at 12:47 PM, Ralph Castain  wrote:
>
> How are they going to review it, given they don't have authority to do
> anything on that branch? Can they still comment? Can they reassign them
> when done?
>
> Yes, they can comment.
>
> The idea was that they would apply the "reviewed" label when they have
> reviewed it successfully.  These "reviewed" labels will then be easily
> viewable in the PR listing by the RM/GK to know which ones are ready.
>
>
> ___
> 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/2014/10/15988.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/2014/10/15990.php
>

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Jeff Squyres (jsquyres)]

Ralph --

I lied, sorry.

You can assign the PR to someone (and assign a milestone and labels) *after* 
you create it.  This is different than Trac where you could set the title, 
body, and all those values and *then* create the ticket.

See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for a little more 
detail.

[cid:B40FFE2B-ADFE-4F67-B91E-50FCCD8B967B@cisco.com]


On Oct 2, 2014, at 12:43 PM, Jeff Squyres 
> wrote:

On Oct 2, 2014, at 12:37 PM, Ralph Castain 
> wrote:

Sonow that I've fought thru and created a pull request, I find that I 
cannot assign it to anyone for review. The only users on the ompi-release 
branch are myself and Jeff (plus the ompiteam admin).

So how do we assign someone to review it?

I think the best way is to do an @mention of someone in the comment.  E.g., in 
this case, "@osvegis, can you review this?"

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



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

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Jeff Squyres (jsquyres)]

You can only assign a label and milestone, and assign the PR to someone, 
*after* you create the PR (same with creating issues).

See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:

[cid:41E9C244-C34D-4E68-89F9-6CE6DFE8B729@cisco.com]




On Oct 2, 2014, at 11:37 PM, Gilles Gouaillardet 
> wrote:

Jeff,

i could not find how to apply a label to a PR via the web interface (and
i am not sure i can even do that since authority might be required)

any idea (maybe a special keyword in the comment ...) ?

Cheers,

Gilles

On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
On Oct 2, 2014, at 12:47 PM, Ralph Castain 
> wrote:

How are they going to review it, given they don't have authority to do anything 
on that branch? Can they still comment? Can they reassign them when done?
Yes, they can comment.

The idea was that they would apply the "reviewed" label when they have reviewed 
it successfully.  These "reviewed" labels will then be easily viewable in the 
PR listing by the RM/GK to know which ones are ready.


___
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/2014/10/15988.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] OMPI@GitHub: (Mostly) Open for business

[Jeff Squyres (jsquyres)]

On Oct 2, 2014, at 11:33 PM, Gilles Gouaillardet 
 wrote:

> the most painful part is probably to manually retrieve the git commit id
> of a given svn commit id
> 
> git log master, and then search r
> /* each commit log has a line like :
> This commit was SVN rx
> */

I think you're suggesting "git log | grep SVN rxxx", right?

> and once you got (all) the git commits id of a given CMR, you can
> cherry-pick them, and push and issue the PR
> 
> /* i did not check whether cherry-pick automatically create/remove files */

It does.  See 
https://github.com/open-mpi/ompi/wiki/InitialGitSetup#workflow-for-cherry-pick-model
 for 2 examples using cherry pick.

That being said, this just be an additional complication for dealing with these 
final CMRs.

One suggestion: if you use "git cherry-pick ...", PLEASE use the "-x" option so 
that it records in the commit message that this commit is a cherry pick from 
the source commit on "master".

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

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Gilles Gouaillardet]

Jeff,

i could not find how to apply a label to a PR via the web interface (and
i am not sure i can even do that since authority might be required)

any idea (maybe a special keyword in the comment ...) ?

Cheers,

Gilles

On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 12:47 PM, Ralph Castain  wrote:
>
>> How are they going to review it, given they don't have authority to do 
>> anything on that branch? Can they still comment? Can they reassign them when 
>> done?
> Yes, they can comment.
>
> The idea was that they would apply the "reviewed" label when they have 
> reviewed it successfully.  These "reviewed" labels will then be easily 
> viewable in the PR listing by the RM/GK to know which ones are ready.
>

Re: [OMPI devel] OMPI@GitHub: (Mostly) Open for business

[Gilles Gouaillardet]

Ralph,

what about cherry-pick ?

the most painful part is probably to manually retrieve the git commit id
of a given svn commit id

git log master, and then search r
/* each commit log has a line like :
This commit was SVN rx
*/

and once you got (all) the git commits id of a given CMR, you can
cherry-pick them,
and push and issue the PR

/* i did not check whether cherry-pick automatically create/remove files */

Cheers,

Gilles

On 2014/10/03 0:51, Ralph Castain wrote:
> I agree that someone needs to do it. However, what isn't clear is *how* to do 
> it. I get the mechanics:
>
> * clone the ompi-release 1.8 branch
> * apply the required change
> * issue a pull request
>
> It's the second step that isn't clear. How the heck do I (a) find the change 
> that was originally applied, and (b) apply it to my clone of ompi-release???
>
> Do I just download the changeset(s) from Trac and patch them in? I guess that 
> will work if we don't have an alternative method.
>
>
> On Oct 2, 2014, at 3:41 AM, Jeff Squyres (jsquyres)  
> wrote:
>
>> Fair enough.
>>
>> *Someone* needs to re-file those CMRs as pull requests; probably in some 
>> cases it's the reporter, probably in some cases it's the owner.  :-)
>>
>>
>> On Oct 2, 2014, at 6:33 AM, Gilles Gouaillardet 
>>  wrote:
>>
>>> Hi Jeff,
>>>
>>> thumbs up for the migration !
>>>
>>> the names here are the CMR owners ('Owned by' field in TRAC)
>>> should it be the duty of the creators ('Reported by' field in TRAC) to
>>> re-create the CMR instead?
>>>
>>> /* if not, and from a git log point of view, that means the commiter
>>> will be the reviewer and not the reporter */
>>>
>>> what do you think ?
>>>
>>> Cheers,
>>>
>>> Gilles
>>>
>>> On 2014/10/02 19:24, Jeff Squyres (jsquyres) wrote:
 2. The following still-open CMRs were not brought over, and need to be 
 re-filed as pull requests:

 - https://svn.open-mpi.org/trac/ompi/ticket/4216: Nathan (BLOCKER)
 - https://svn.open-mpi.org/trac/ompi/ticket/4816: Ralph
 - https://svn.open-mpi.org/trac/ompi/ticket/4872: Ralph
 - https://svn.open-mpi.org/trac/ompi/ticket/4888: Howard
 - https://svn.open-mpi.org/trac/ompi/ticket/4900: Ralph
 - https://svn.open-mpi.org/trac/ompi/ticket/4905: Mike Dubman
 - https://svn.open-mpi.org/trac/ompi/ticket/4917: Jeff
 - https://svn.open-mpi.org/trac/ompi/ticket/4911: Jeff
 - https://svn.open-mpi.org/trac/ompi/ticket/4922: Jeff
 - https://svn.open-mpi.org/trac/ompi/ticket/4923: Ralph
 - https://svn.open-mpi.org/trac/ompi/ticket/4925: OMPI RM 1.8
 - https://svn.open-mpi.org/trac/ompi/ticket/4926: Oscar
 - https://svn.open-mpi.org/trac/ompi/ticket/4927: Jeff
>>> ___
>>> 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/2014/10/15966.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/2014/10/15967.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/2014/10/15971.php