Re: [OMPI devel] Issue/PR tagging

[r...@open-mpi.org]

Okay - thanks!

> On Jul 19, 2017, at 4:47 PM, Barrett, Brian via devel 
>  wrote:
> 
> I’ll update the wiki (and figure out where on our wiki to put more general 
> information), but the basics are:
> 
> If you find a bug, file an issue.  Add Target:v??? labels for any branch it 
> impacts.  If we decide later not to fix the issue on a branch, we’ll remove 
> the label
> Open/find an issue for any PR going to release branches.  That issue can 
> (possibly should, if the issue impacts multiple branches) have multiple 
> Target:v??? labels
> If a PR is for a release branch (ie, it’s immediate target to merge to is a 
> release branch), please add a Target:v??? label and reference the issue
> If a PR is for master, it can reference an issue (if there’s an issue 
> associated with it), but should not have a Target:v??? label
> If an issue is fixed in master, but not merged into branches, don’t close the 
> issue
> 
> I think that’s about it.  There’s some workflows we want to build to automate 
> enforcing many of these things, but for now, it’s just hints to help the RMs 
> not lose track of issues.
> 
> Brian
> 
>> On Jul 19, 2017, at 12:18 PM, r...@open-mpi.org wrote:
>> 
>> Hey folks
>> 
>> I know we made some decisions last week about how to tag issues and PRs to 
>> make things easier to track for release branches, but the wiki notes don’t 
>> cover what we actually decided to do. Can someone briefly summarize? I 
>> honestly have forgotten if we tag issues, or tag PRs
>> 
>> Ralph
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Issue/PR tagging

[Barrett, Brian via devel]

I’ll update the wiki (and figure out where on our wiki to put more general 
information), but the basics are:

If you find a bug, file an issue.  Add Target:v??? labels for any branch it 
impacts.  If we decide later not to fix the issue on a branch, we’ll remove the 
label
Open/find an issue for any PR going to release branches.  That issue can 
(possibly should, if the issue impacts multiple branches) have multiple 
Target:v??? labels
If a PR is for a release branch (ie, it’s immediate target to merge to is a 
release branch), please add a Target:v??? label and reference the issue
If a PR is for master, it can reference an issue (if there’s an issue 
associated with it), but should not have a Target:v??? label
If an issue is fixed in master, but not merged into branches, don’t close the 
issue

I think that’s about it.  There’s some workflows we want to build to automate 
enforcing many of these things, but for now, it’s just hints to help the RMs 
not lose track of issues.

Brian

> On Jul 19, 2017, at 12:18 PM, r...@open-mpi.org wrote:
> 
> Hey folks
> 
> I know we made some decisions last week about how to tag issues and PRs to 
> make things easier to track for release branches, but the wiki notes don’t 
> cover what we actually decided to do. Can someone briefly summarize? I 
> honestly have forgotten if we tag issues, or tag PRs
> 
> Ralph
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

[OMPI devel] Issue/PR tagging

[r...@open-mpi.org]

Hey folks

I know we made some decisions last week about how to tag issues and PRs to make 
things easier to track for release branches, but the wiki notes don’t cover 
what we actually decided to do. Can someone briefly summarize? I honestly have 
forgotten if we tag issues, or tag PRs

Ralph

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] MTT / Open MPI Visibility of New Failures

[Josh Hursey]

We are putting a pin in this for now. Amazon had an idea they wanted to run
with and report back. Once they have more info then we'll try to setup
another meeting.

On Tue, Jul 11, 2017 at 3:20 PM, Josh Hursey  wrote:

> In the Open MPI face-to-face meeting we had a long discussion about how to
> better harness MTT such that new failures are identified and the community
> alerted to their existence. The current manual way is not working. Our
> ultimate goal here is to know if we are making forward progress, and if
> something new fails the community knows about it immediately and
> automatically.
>
> We had a bunch of discussion and decided to think it over some more then
> come back to a teleconf in the next week or two to make a plan. The MTT
> group is scheduled to meet on Thursday, July 20 at 4 pm EST. We already
> know that doesn't work for everyone interested so I setup a doodle poll to
> pick a time for this specific discussion.
>
>   https://doodle.com/poll/8zdetnnv4iaaawg4
>
> *Please fill out the doodle poll by Thursday, July 13, 2017 at 5 pm EST.
> I'll pick a time then.*
>
>
>
> Three topics were identified to make progress.
>  1. Move MTT (Perl) Client to new server submission interface
>  2. Adding an "expected fail" list to MTT Client.
>  3. Drive the number of MTT reported failures to 0
>
> (1) This will start the movement to the new RESTful MTT server. Eventually
> we want to disable the old PHP submission mechanism. This is a first step.
> Josh needs to re-test this interface to confirm it is still working as
> expected with the existing 'v3' database.
>
> (2) For each branch/test-suite/runtime-configuration identify a test run
> as "known to fail". These will be flagged in the MTT Database and MTT
> Viewer/Reporter as separate from other failures ("failed, but we expected
> to pass"). Is this part of the INI file or a separate 'thing'?
>
> (3) The idea is that the "failed, but we expected to pass" number should
> be 0 for all sites. The individual site is responsible for maintaining
> their "known to fail" list. If the "failed, but we expected to pass" number
> is >0 then this is a 'new failure' and an email to the community is
> generated.
>
>
> --
> Josh Hursey
> IBM Spectrum MPI Developer
>



-- 
Josh Hursey
IBM Spectrum MPI Developer
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel