Guys, you are way off-base here. This is why Jeff asked that we table this
conversation until the devel meeting. As he and I discussed at length on the
phone, your starting premise is incorrect.
This entire thread stems from Jeff’s recent attempt to do a bisect search on
the master. He hit seve
On Tue, May 19, 2015 at 9:37 PM, Howard Pritchard
wrote:
> Pretty soon the developer will get trained to use the PR process, unless
> they are that engineer I've yet to meet who always writes flawless code.
I've never met that developer, either.
However, I have met one (and thankfully only one)
On 20/05/15 14:37, Howard Pritchard wrote:
> It would also be easy to trap the I-want-to-bypass-PR-because-I
> know-what-I'm-doing-developer with a second level of protection. Just
> set up a jenkins project that does a smoke test after ever commit to
> master. If the smoke test fails, send a na
Hi Dave,
> The other way to solve this issue would be to stop treating the master as
> a general dumping ground for potentially unstable code where anyone can
> just push any time they want. If we switched to using PRs for
> (essentially) all code that goes into master as well, then we wouldn't
I think that now that we have several months of git/github under our belts, it
seems like a natural topic to have in the upcoming face-to-face meeting of:
how's it going? What's going well / not well? What can we improve on?
Let's have this conversation then.
> On May 19, 2015, at 2:22 PM, Ra
On May 19, 2015, at 1:22 PM, Ralph Castain wrote:
> No thx 😉
>
> I would rather not create code czars
Hence my "half version" alternative suggestion.
-Dave
No thx 😉
I would rather not create code czars
Sent from my iPhone
> On May 19, 2015, at 12:11 PM, Dave Goodell (dgoodell)
> wrote:
>
>> On May 19, 2015, at 12:36 PM, Ralph Castain wrote:
>>
>> Our pr tests aren't good enough for what you propose
>
> I made no claim about whether PRs even
On May 19, 2015, at 12:36 PM, Ralph Castain wrote:
> Our pr tests aren't good enough for what you propose
I made no claim about whether PRs even needed automated testing in order to
switch to this scheme. Right now I could push any old garbage I want into the
master directly without ever usin
Our pr tests aren't good enough for what you propose
Sent from my iPhone
> On May 19, 2015, at 11:12 AM, Dave Goodell (dgoodell)
> wrote:
>
>> On May 19, 2015, at 5:08 AM, Jeff Squyres (jsquyres)
>> wrote:
>>
>>> On May 18, 2015, at 5:03 PM, Mark Santcroos
>>> wrote:
>>>
>>> What I didn
On May 19, 2015, at 5:08 AM, Jeff Squyres (jsquyres) wrote:
> On May 18, 2015, at 5:03 PM, Mark Santcroos
> wrote:
>
>> What I didn't see in the doc, will you continue to work with two repo's or
>> will that change too?
>> (I found that confusing as a newcomer)
>
> Unfortunately, yes, we wil
On May 18, 2015, at 5:03 PM, Mark Santcroos wrote:
>
> Thanks for bringing this to the wider community.
>
> I hope this will eventually address my main concern: the relatively old
> versions that get deployed on HPC systems around the world, which I assume
> is/was because of the "odd ;-)" num
On 19/05/15 05:11, Jeff Squyres (jsquyres) wrote:
> We've reached internal consensus, and would like to present this to the
> larger community for feedback.
My gut feeling is that this is very good; from a cluster admin point of
view it means we keep a system tracking one level up from where we
Hi Mark,
ideally, we would like to use a single repository with the following
constraints :
- all Open MPI developers can commit to the master
- only Release Manager and Gatekeepers can commit to the release branch
(v1.8, ...)
unfortunatly, github does not (yet ?) implement per branch access
Hi Jeff, all,
Thanks for bringing this to the wider community.
I hope this will eventually address my main concern: the relatively old
versions that get deployed on HPC systems around the world, which I assume
is/was because of the "odd ;-)" numbering.
What I didn't see in the doc, will you co
Devel community --
Over the past few weeks, the core Open MPI members have been internally
discussing a proposal to change to the version numbering of Open MPI public
releases. We've reached internal consensus, and would like to present this to
the larger community for feedback.
Here's the sh
15 matches
Mail list logo
