Re: [VOTE] Move the project repos to gitbox

[Gastón Kleiman]

On Tue, Jul 17, 2018 at 7:59 AM Vinod Kone  wrote:

> Hi,
>
> As discussed in another thread and in the committers sync, there seem to be
> heavy interest in moving our project repos ("mesos", "mesos-site") from the
> "git-wip" git server to the new "gitbox" server to better avail GitHub
> integrations.
>
> Please vote +1, 0, -1 regarding the move to gitbox. The vote will close in
> 3 business days.
>

+1

Re: Backport Policy

[Lawrence Rau]

I don’t have a big stake in, however, one opinion is if a large commercial 
enterprise was using a specific release that is working the desire is often to 
only upgrade if necessary.  Necessary can be for a number of reasons including 
new features; however if a new feature is not needed the compelling reason to 
upgrade is to fix a specific problem that is causing issues.  Thus keeping a 
maintenance release stable is very important and reducing the chance for, while 
fixing one problem, introducing another.

Often a clear classification of severity of the problem would dictate the need 
to make a change. (yes these can be subjective, but some guidance would be 
better than nothing).

It might be good to give committers guidance on back porting things that have a 
high impact on improving a problem.  Fixing a crashing bug, fixing a 
degenerative performance issue, etc, where these issues have no easy/viable 
work around.  Nice to have fixes aren’t, always, worth updating to.  

There can be an argument to respond with a “then don’t upgrade” but if changing 
the release with “nice to have’s” and several point releases later when a 
critical bug is fixed then the org if forced to accept the risk of the nice to 
have’s.

just an opinion.
…larry

> On Jul 17, 2018, at 3:00 PM, Chun-Hung Hsiao  wrote:
> 
> I just have a comment on a special case:
> If a fix for a flaky test is easy to backport,
> IMO we probably should backport it,
> otherwise if someone backports another critical fix in the future,
> it would take them extra effort to check all CI failures.
> 
> On Mon, Jul 16, 2018 at 11:39 AM Vinod Kone  > wrote:
> I like how you summarized it Greg and I would vote for leaving the decision
> to the committer too. In addition to what others mentioned, I think
> committer should've the responsibility because if things break in a point
> release (after it is released), it is the committer and contributor who are
> on the hook to triage and fix it and not the release manager.
> 
> Having said that, if "during" the release process (i.e., cutting an RC)
> these backports cause delays for a release manager in getting the release
> out (e.g., CI flakiness introduced due to backports), release manager could
> be the ultimate arbiter on whether such a backport should be reverted or
> fixed by the committer/contributor. Hopefully such issues are caught much
> before a release process is started (e.g., CI running against release
> branches).
> 
> On Mon, Jul 16, 2018 at 1:28 PM Jie Yu  > wrote:
> 
> > Greg, I like your idea of adding a prescriptive "policy" when evaluating
> > whether a bug fix should be backported, and leave the decision to committer
> > (because they have the most context, and avoid a bottleneck in the
> > process).
> >
> > - Jie
> >
> > On Mon, Jul 16, 2018 at 11:24 AM, Greg Mann  > > wrote:
> >
> > > My impression is that we have two opposing schools of thought here:
> > >
> > >1. Backport as little as possible, to avoid unforeseen consequences
> > >2. Backport as much as proves practical, to eliminate bugs in
> > >supported versions
> > >
> > > Do other people agree with this assessment?
> > >
> > > If so, how can we find common ground? One possible solution would be to
> > > leave the decision on backporting up to the committer, without
> > specifying a
> > > project-wide policy. This seems to be the status quo, and would lead to
> > > some variation across committers regarding what types of fixes are
> > > backported. We could also choose to delegate the decision to the release
> > > manager; I favor leaving the decision with the committer, to eliminate
> > the
> > > burden on release managers.
> > >
> > > Here's a thought: rather than defining a prescriptive "policy" that we
> > > expect committers to abide by, we could enumerate in the documentation
> > the
> > > competing concerns that we expect committers to consider when making
> > > decisions on backports. The committing docs could read something like:
> > >
> > > "When bug fixes are committed to master, the committer should evaluate
> > the
> > > fix to determine whether or not it should be backported to supported
> > > versions. This is left to the committer, but they are expected to weigh
> > the
> > > following concerns when making the decision:
> > >
> > >- Every backported change comes with a risk of unintended
> > >consequences. The change should be carefully evaluated to ensure that
> > such
> > >side-effects are highly unlikely.
> > >- As the complexity of applying a backport increases due to merge
> > >conflicts, the likelihood of unintended consequences also increases.
> > Bug
> > >fixes which require extensive rebasing should only be backported when
> > the
> > >bug is critical enough to warrant the risk.
> > >- Users of supported versions benefit greatly from the resolution of
> > >bugs in point 

Re: Operations Working Group - First Meeting

[Chun-Hung Hsiao]

Unfortunately the time conflicts with the CSI community sync so I'll have
to skip :(

On Tue, Jul 17, 2018 at 2:55 AM Abel Souza  wrote:

> Thank you for setting this up Gaston,
>
> Would you mind giving us a brief of what you have in mind for discussion?
>
> Thank you,
>
> Abel
>
> On 07/17/2018 10:52 AM, Matt Jarvis wrote:
>
> That's great news Gaston ! Let me know if you need any help from the
> Community team.
>
> Matt
>
> On Tue, 17 Jul 2018, 05:04 Gastón Kleiman,  wrote:
>
>> Hi all,
>>
>> Thank you for responding to my previous emails - I think that we have
>> quorum for a new working group!
>>
>> Many of you who have expressed interest seem to be in Europe, so I tried
>> schedule the first meeting at a time that I hope will be friendly for
>> people in both GMT+1 and GMT-8:
>>
>> *Date:* Wednesday July 25th from 9:00-10:00 AM PDT
>> *Agenda:*
>> https://docs.google.com/document/d/1XjJfoksz70vbTvvT6FQ1t_J0SD1XIoipmYSvEHJfXt8/
>> *Zoom URL:* https://zoom.us/j/310132146
>> 
>>
>> You can also find the event in the Mesos Community Calendar.
>>
>> Feel free to add more topics to the agenda.
>>
>> Looking forward to meeting you all next week,
>>
>> -Gastón
>>
>
>

Re: Backport Policy

[Chun-Hung Hsiao]

I just have a comment on a special case:
If a fix for a flaky test is easy to backport,
IMO we probably should backport it,
otherwise if someone backports another critical fix in the future,
it would take them extra effort to check all CI failures.

On Mon, Jul 16, 2018 at 11:39 AM Vinod Kone  wrote:

> I like how you summarized it Greg and I would vote for leaving the decision
> to the committer too. In addition to what others mentioned, I think
> committer should've the responsibility because if things break in a point
> release (after it is released), it is the committer and contributor who are
> on the hook to triage and fix it and not the release manager.
>
> Having said that, if "during" the release process (i.e., cutting an RC)
> these backports cause delays for a release manager in getting the release
> out (e.g., CI flakiness introduced due to backports), release manager could
> be the ultimate arbiter on whether such a backport should be reverted or
> fixed by the committer/contributor. Hopefully such issues are caught much
> before a release process is started (e.g., CI running against release
> branches).
>
> On Mon, Jul 16, 2018 at 1:28 PM Jie Yu  wrote:
>
> > Greg, I like your idea of adding a prescriptive "policy" when evaluating
> > whether a bug fix should be backported, and leave the decision to
> committer
> > (because they have the most context, and avoid a bottleneck in the
> > process).
> >
> > - Jie
> >
> > On Mon, Jul 16, 2018 at 11:24 AM, Greg Mann  wrote:
> >
> > > My impression is that we have two opposing schools of thought here:
> > >
> > >1. Backport as little as possible, to avoid unforeseen consequences
> > >2. Backport as much as proves practical, to eliminate bugs in
> > >supported versions
> > >
> > > Do other people agree with this assessment?
> > >
> > > If so, how can we find common ground? One possible solution would be to
> > > leave the decision on backporting up to the committer, without
> > specifying a
> > > project-wide policy. This seems to be the status quo, and would lead to
> > > some variation across committers regarding what types of fixes are
> > > backported. We could also choose to delegate the decision to the
> release
> > > manager; I favor leaving the decision with the committer, to eliminate
> > the
> > > burden on release managers.
> > >
> > > Here's a thought: rather than defining a prescriptive "policy" that we
> > > expect committers to abide by, we could enumerate in the documentation
> > the
> > > competing concerns that we expect committers to consider when making
> > > decisions on backports. The committing docs could read something like:
> > >
> > > "When bug fixes are committed to master, the committer should evaluate
> > the
> > > fix to determine whether or not it should be backported to supported
> > > versions. This is left to the committer, but they are expected to weigh
> > the
> > > following concerns when making the decision:
> > >
> > >- Every backported change comes with a risk of unintended
> > >consequences. The change should be carefully evaluated to ensure
> that
> > such
> > >side-effects are highly unlikely.
> > >- As the complexity of applying a backport increases due to merge
> > >conflicts, the likelihood of unintended consequences also increases.
> > Bug
> > >fixes which require extensive rebasing should only be backported
> when
> > the
> > >bug is critical enough to warrant the risk.
> > >- Users of supported versions benefit greatly from the resolution of
> > >bugs in point releases. Thus, whenever concerns #1 and #2 can be
> > allayed
> > >for a given bug fix, it should be backported."
> > >
> > >
> > > Cheers,
> > > Greg
> > >
> > >
> > > On Mon, Jul 16, 2018 at 3:06 AM, Alex Rukletsov 
> > > wrote:
> > >
> > >> Back porting as little as possible is the ultimate goal for me. My
> > >> reasons are closely aligned with what Andrew wrote above.
> > >>
> > >> If we agree on this strategy, the next question is how to enforce it.
> My
> > >> intuition is that committers will lean towards back porting their
> > patches
> > >> in arguable cases, because humans tend to overestimate the importance
> of
> > >> their personal work. Delegating the decision in such cases to a
> release
> > >> manager in my opinion will help us enforce the strategy of minimal
> > number
> > >> backports. As a bonus, the release manager will have a much better
> > >> understanding of what's going on with the release, keyword: "more
> > >> ownership".
> > >>
> > >> On Sat, Jul 14, 2018 at 12:07 AM, Andrew Schwartzmeyer <
> > >> and...@schwartzmeyer.com> wrote:
> > >>
> > >>> I believe I fall somewhere between Alex and Ben.
> > >>>
> > >>> As for deciding what to backport or not, I lean toward Alex's view of
> > >>> backporting as little as possible (and agree with his criteria). My
> > >>> reasoning is that all changes can have unforeseen consequences,
> which I
> > >>> believe is something to be 

Re: [VOTE] Move the project repos to gitbox

[Greg Mann]

+1

On Tue, Jul 17, 2018 at 9:39 AM, Jie Yu  wrote:

> +1
>
> On Tue, Jul 17, 2018 at 9:38 AM, Andrew Schwartzmeyer <
> and...@schwartzmeyer.com> wrote:
>
>> +1
>>
>>
>>
>> On 07/17/2018 8:54 am, Zhitao Li wrote:
>>
>> +1
>>
>> On Tue, Jul 17, 2018 at 8:10 AM James Peach  wrote:
>>
>>>
>>>
>>> > On Jul 17, 2018, at 7:58 AM, Vinod Kone  wrote:
>>> >
>>> > Hi,
>>> >
>>> > As discussed in another thread and in the committers sync, there seem
>>> to be heavy interest in moving our project repos ("mesos", "mesos-site")
>>> from the "git-wip" git server to the new "gitbox" server to better avail
>>> GitHub integrations.
>>> >
>>> > Please vote +1, 0, -1 regarding the move to gitbox. The vote will
>>> close in 3 business days.
>>>
>>>
>>> +1
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>>
>

Re: [VOTE] Move the project repos to gitbox

[Jie Yu]

+1

On Tue, Jul 17, 2018 at 9:38 AM, Andrew Schwartzmeyer <
and...@schwartzmeyer.com> wrote:

> +1
>
>
>
> On 07/17/2018 8:54 am, Zhitao Li wrote:
>
> +1
>
> On Tue, Jul 17, 2018 at 8:10 AM James Peach  wrote:
>
>>
>>
>> > On Jul 17, 2018, at 7:58 AM, Vinod Kone  wrote:
>> >
>> > Hi,
>> >
>> > As discussed in another thread and in the committers sync, there seem
>> to be heavy interest in moving our project repos ("mesos", "mesos-site")
>> from the "git-wip" git server to the new "gitbox" server to better avail
>> GitHub integrations.
>> >
>> > Please vote +1, 0, -1 regarding the move to gitbox. The vote will close
>> in 3 business days.
>>
>>
>> +1
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
>

Re: [VOTE] Move the project repos to gitbox

[Andrew Schwartzmeyer]

 +1

On 07/17/2018 8:54 am, Zhitao Li wrote: 

> +1 
> 
> On Tue, Jul 17, 2018 at 8:10 AM James Peach  wrote: 
> 
>>> On Jul 17, 2018, at 7:58 AM, Vinod Kone  wrote:
>>> 
>>> Hi,
>>> 
>>> As discussed in another thread and in the committers sync, there seem to be 
>>> heavy interest in moving our project repos ("mesos", "mesos-site") from the 
>>> "git-wip" git server to the new "gitbox" server to better avail GitHub 
>>> integrations.
>>> 
>>> Please vote +1, 0, -1 regarding the move to gitbox. The vote will close in 
>>> 3 business days.
>> 
>> +1
> 
> -- 
> 
> Cheers,
> 
> Zhitao Li
 

Re: [VOTE] Move the project repos to gitbox

[Zhitao Li]

+1

On Tue, Jul 17, 2018 at 8:10 AM James Peach  wrote:

>
>
> > On Jul 17, 2018, at 7:58 AM, Vinod Kone  wrote:
> >
> > Hi,
> >
> > As discussed in another thread and in the committers sync, there seem to
> be heavy interest in moving our project repos ("mesos", "mesos-site") from
> the "git-wip" git server to the new "gitbox" server to better avail GitHub
> integrations.
> >
> > Please vote +1, 0, -1 regarding the move to gitbox. The vote will close
> in 3 business days.
>
>
> +1



-- 
Cheers,

Zhitao Li

Re: [VOTE] Move the project repos to gitbox

[James Peach]

> On Jul 17, 2018, at 7:58 AM, Vinod Kone  wrote:
> 
> Hi,
> 
> As discussed in another thread and in the committers sync, there seem to be 
> heavy interest in moving our project repos ("mesos", "mesos-site") from the 
> "git-wip" git server to the new "gitbox" server to better avail GitHub 
> integrations.
> 
> Please vote +1, 0, -1 regarding the move to gitbox. The vote will close in 3 
> business days.


+1

[VOTE] Move the project repos to gitbox

[Vinod Kone]

Hi,

As discussed in another thread and in the committers sync, there seem to be
heavy interest in moving our project repos ("mesos", "mesos-site") from the
"git-wip" git server to the new "gitbox" server to better avail GitHub
integrations.

Please vote +1, 0, -1 regarding the move to gitbox. The vote will close in
3 business days.

Thanks,
Vinod

Re: Operations Working Group - First Meeting

[Abel Souza]

Thank you for setting this up Gaston,

Would you mind giving us a brief of what you have in mind for discussion?

Thank you,

Abel


On 07/17/2018 10:52 AM, Matt Jarvis wrote:
That's great news Gaston ! Let me know if you need any help from the 
Community team.


Matt

On Tue, 17 Jul 2018, 05:04 Gastón Kleiman, > wrote:


Hi all,

Thank you for responding to my previous emails - I think that we
have quorum for a new working group!

Many of you who have expressed interest seem to be in Europe, so I
tried schedule the first meeting at a time that I hope will be
friendly for people in both GMT+1 and GMT-8:

*Date:* Wednesday July 25th from 9:00-10:00 AM PDT
*Agenda:*

https://docs.google.com/document/d/1XjJfoksz70vbTvvT6FQ1t_J0SD1XIoipmYSvEHJfXt8/
*Zoom URL:* https://zoom.us/j/310132146



You can also find the event in the Mesos Community Calendar.

Feel free to add more topics to the agenda.

Looking forward to meeting you all next week,

-Gastón

Re: Operations Working Group - First Meeting

[Matt Jarvis]

That's great news Gaston ! Let me know if you need any help from the
Community team.

Matt

On Tue, 17 Jul 2018, 05:04 Gastón Kleiman,  wrote:

> Hi all,
>
> Thank you for responding to my previous emails - I think that we have
> quorum for a new working group!
>
> Many of you who have expressed interest seem to be in Europe, so I tried
> schedule the first meeting at a time that I hope will be friendly for
> people in both GMT+1 and GMT-8:
>
> *Date:* Wednesday July 25th from 9:00-10:00 AM PDT
> *Agenda:*
> https://docs.google.com/document/d/1XjJfoksz70vbTvvT6FQ1t_J0SD1XIoipmYSvEHJfXt8/
> *Zoom URL:* https://zoom.us/j/310132146
> 
>
> You can also find the event in the Mesos Community Calendar.
>
> Feel free to add more topics to the agenda.
>
> Looking forward to meeting you all next week,
>
> -Gastón
>