Re: Apache Mesos Community Sync

[Adam Bordelon]

It's been a while since our last community sync, and tomorrow, Thursday Nov
5th shows up on my calendar as a 3pm Twitter-hosted meeting, since those
have traditionally been "Monthly on the first Thursday". After this, the
other meetings (third Thursday, or every other week?) can alternate between
9pm/9am. Let's get these on the calendar officially.

Vinod, are you/Twitter still planning to host the community sync tomorrow?

On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon  wrote:

> We'll have the next community sync this Thursday (Oct. 15th) from 9-10am
> Pacific.
>
> Please add items to the agenda
> 
> .
>
> We will use Hangouts on Air again. We will post the video stream link
> shortly before the meeting, and only active participants (especially people
> on the agenda) should join the actual hangout. Others can watch the video
> stream and ask brief questions on #mesos on IRC. If you have something
> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
> into the hangout.
>
> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
> reception on the 2nd floor.
>
>
> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>
>> Got it. Thank you.
>>
>> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
>> wrote:
>>
>> > Yes, community sync is at 3 pm PST today afternoon. Video Link is still
>> not
>> > available. And here is the link for meeting agenda/notes:
>> >
>> >
>> >
>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>> >
>> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
>> >
>> > > Do today have community sync?
>> > >
>> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon 
>> > > wrote:
>> > >
>> > > > Today's community sync video/audio is archived at:
>> > > > http://youtu.be/ZQT6-fw8Ito
>> > > > The meeting agenda/notes are available at:
>> > > >
>> > > >
>> > >
>> >
>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>> > > >
>> > > > For convenience, today's notes are reproduced below:
>> > > >
>> > > >-
>> > > >
>> > > >0.21.2-0.24.1 Patch Releases [Adam]
>> > > >-
>> > > >
>> > > >   What’s the plan for how many releases we want to support?
>> BenH:
>> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x) for
>> > > > which we will
>> > > >   do patch fixes
>> > > >   Neil: Or support an LTS version + recent releases
>> > > >   -
>> > > >
>> > > >   Separate Release Manager for backports? Joris and MPark will
>> RM
>> > for
>> > > >   these patch releases, with Adam shepherding. In general,
>> > > patch/point
>> > > >   releases don’t need to be managed by the same person who did
>> the
>> > > > original
>> > > >   release.
>> > > >   -
>> > > >
>> > > >   Need some guidelines (on the website) for what is a
>> > > >   backport-able/critical patch.
>> > > >   -
>> > > >
>> > > >   AI[Adam+0.25RMs]: Expand Release Guide with # supported
>> releases,
>> > > >   guidelines for critical patches, RM roles/responsibilities
>> > > >   -
>> > > >
>> > > >0.25.0 Release Planning[Joris]: Dashboard
>> > > ><
>> > > >
>> > >
>> >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326859
>> > > > >
>> > > >-
>> > > >
>> > > >   Planning a triage meeting for Friday, hope to cut 0.25.0-rc1
>> by
>> > > Sept.
>> > > >   23rd.
>> > > >   -
>> > > >
>> > > >MesosCon EU [Adam]: Schedule announced!
>> > > > http://mesosconeu2015.sched.org/
>> > > >-
>> > > >
>> > > >   Register! Attend! Meet cool people! Learn awesome things!
>> > > >   -
>> > > >
>> > > >   Want to grow developer community as well as user community
>> > > >   -
>> > > >
>> > > >   Community voting vs. Program Committee selection?
>> > > >   -
>> > > >
>> > > >Mesos Developer Community Sync Frequency to weekly [Joris, BenH]
>> > > >-
>> > > >
>> > > >   Rotating time for time zones
>> > > >   -
>> > > >
>> > > >   Weeklys can be video/hangout
>> > > >   -
>> > > >
>> > > >   1/mo can be on-site @Twitter/Mesosphere/etc
>> > > >   -
>> > > >
>> > > >   AI [Joris]: Send out email proposal for times, weekly schedule
>> > > >   -
>> > > >
>> > > >   Proposal: Send each meeting’s notes to dev list (in plain
>> text)
>> > > >   afterwards
>> > > >   -
>> > > >
>> > > >ReviewBot needs more OS/Compiler coverage [Joseph, Joris]
>> > > >-
>> > > >
>> > > >   ReviewBot != Jenkins continuous build
>> > > >   -
>> > > >
>> > > >MESOS-3147: Allocator Refactor project kick off, want to discuss
>> > more
>> > > >for how we can proceed this. [Guangya, MPark, AlexR]
>> > > >-
>> > > >
>> > > >   Shepherd: MPark
>> 

Re: Apache Mesos Community Sync

[Jie Yu]

Adam, since most of the Twitter folks are OOO this week. I chatted with
Artem/Vinod. we think it makes sense to host the sync at Mesosphere
tomorrow.

- Jie

On Wed, Nov 4, 2015 at 4:22 PM, Adam Bordelon  wrote:

> It's been a while since our last community sync, and tomorrow, Thursday
> Nov 5th shows up on my calendar as a 3pm Twitter-hosted meeting, since
> those have traditionally been "Monthly on the first Thursday". After
> this, the other meetings (third Thursday, or every other week?) can
> alternate between 9pm/9am. Let's get these on the calendar officially.
>
> Vinod, are you/Twitter still planning to host the community sync tomorrow?
>
> On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon  wrote:
>
>> We'll have the next community sync this Thursday (Oct. 15th) from 9-10am
>> Pacific.
>>
>> Please add items to the agenda
>> 
>> .
>>
>>
>> We will use Hangouts on Air again. We will post the video stream link
>> shortly before the meeting, and only active participants (especially people
>> on the agenda) should join the actual hangout. Others can watch the video
>> stream and ask brief questions on #mesos on IRC. If you have something
>> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
>> into the hangout.
>>
>> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
>> reception on the 2nd floor.
>>
>>
>> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>>
>>> Got it. Thank you.
>>>
>>> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
>>> wrote:
>>>
>>> > Yes, community sync is at 3 pm PST today afternoon. Video Link is
>>> still not
>>> > available. And here is the link for meeting agenda/notes:
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>> >
>>> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
>>> >
>>> > > Do today have community sync?
>>> > >
>>> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon 
>>> > > wrote:
>>> > >
>>> > > > Today's community sync video/audio is archived at:
>>> > > > http://youtu.be/ZQT6-fw8Ito
>>> > > > The meeting agenda/notes are available at:
>>> > > >
>>> > > >
>>> > >
>>> >
>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>> > > >
>>> > > > For convenience, today's notes are reproduced below:
>>> > > >
>>> > > >-
>>> > > >
>>> > > >0.21.2-0.24.1 Patch Releases [Adam]
>>> > > >-
>>> > > >
>>> > > >   What’s the plan for how many releases we want to support?
>>> BenH:
>>> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x) for
>>> > > > which we will
>>> > > >   do patch fixes
>>> > > >   Neil: Or support an LTS version + recent releases
>>> > > >   -
>>> > > >
>>> > > >   Separate Release Manager for backports? Joris and MPark will
>>> RM
>>> > for
>>> > > >   these patch releases, with Adam shepherding. In general,
>>> > > patch/point
>>> > > >   releases don’t need to be managed by the same person who did
>>> the
>>> > > > original
>>> > > >   release.
>>> > > >   -
>>> > > >
>>> > > >   Need some guidelines (on the website) for what is a
>>> > > >   backport-able/critical patch.
>>> > > >   -
>>> > > >
>>> > > >   AI[Adam+0.25RMs]: Expand Release Guide with # supported
>>> releases,
>>> > > >   guidelines for critical patches, RM roles/responsibilities
>>> > > >   -
>>> > > >
>>> > > >0.25.0 Release Planning[Joris]: Dashboard
>>> > > ><
>>> > > >
>>> > >
>>> >
>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326859
>>> > > > >
>>> > > >-
>>> > > >
>>> > > >   Planning a triage meeting for Friday, hope to cut 0.25.0-rc1
>>> by
>>> > > Sept.
>>> > > >   23rd.
>>> > > >   -
>>> > > >
>>> > > >MesosCon EU [Adam]: Schedule announced!
>>> > > > http://mesosconeu2015.sched.org/
>>> > > >-
>>> > > >
>>> > > >   Register! Attend! Meet cool people! Learn awesome things!
>>> > > >   -
>>> > > >
>>> > > >   Want to grow developer community as well as user community
>>> > > >   -
>>> > > >
>>> > > >   Community voting vs. Program Committee selection?
>>> > > >   -
>>> > > >
>>> > > >Mesos Developer Community Sync Frequency to weekly [Joris, BenH]
>>> > > >-
>>> > > >
>>> > > >   Rotating time for time zones
>>> > > >   -
>>> > > >
>>> > > >   Weeklys can be video/hangout
>>> > > >   -
>>> > > >
>>> > > >   1/mo can be on-site @Twitter/Mesosphere/etc
>>> > > >   -
>>> > > >
>>> > > >   AI [Joris]: Send out email proposal for times, weekly
>>> schedule
>>> > > >   -
>>> > > >
>>> > > >   Proposal: Send each meeting’s notes to dev list (in plain
>>> text)
>>> > > >   afterwards
>>> > > >   -

Fwd: [jira] [Updated] (MESOS-3826) Add an optional unique identifier for resource reservations

[Benjamin Mahler]

Are you actually going to shepherd this michael? We ended up not adding IDs
to these because we wanted dynamic reservations to be symmetric with static
reservations. Needs some thought.

-- Forwarded message --
From: Guangya Liu (JIRA) 
Date: Tue, Nov 3, 2015 at 10:39 PM
Subject: [jira] [Updated] (MESOS-3826) Add an optional unique identifier
for resource reservations
To: iss...@mesos.apache.org



 [
https://issues.apache.org/jira/browse/MESOS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Guangya Liu updated MESOS-3826:
---
Shepherd: Michael Park

> Add an optional unique identifier for resource reservations
> ---
>
> Key: MESOS-3826
> URL: https://issues.apache.org/jira/browse/MESOS-3826
> Project: Mesos
>  Issue Type: Improvement
>  Components: general
>Reporter: Sargun Dhillon
>Assignee: Guangya Liu
>Priority: Minor
>  Labels: mesosphere
>
> Thanks to the resource reservation primitives, frameworks can reserve
resources. These reservations are per role, which means multiple frameworks
can share reservations. This can get very hairy, as multiple reservations
can occur on each agent.
> It would be nice to be able to optionally, uniquely identify reservations
by ID, much like persistent volumes are today. This could be done by adding
a new protobuf field, such as Resource.ReservationInfo.id, that if set upon
reservation time, would come back when the reservation is advertised.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Apache Mesos Community Sync

[Adam Bordelon]

Sounds great! Please join us at Mesosphere HQ, 88 Stevenson St., SF at 3pm
Pacific tomorrow.
We will use youtube-onair again, links to be posted to IRC/email shortly
before the meeting.

Please add agenda items:
https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#heading=h.za1f9dpxisdr

On Wed, Nov 4, 2015 at 4:25 PM, Jie Yu  wrote:

> Adam, since most of the Twitter folks are OOO this week. I chatted with
> Artem/Vinod. we think it makes sense to host the sync at Mesosphere
> tomorrow.
>
> - Jie
>
> On Wed, Nov 4, 2015 at 4:22 PM, Adam Bordelon  wrote:
>
>> It's been a while since our last community sync, and tomorrow, Thursday
>> Nov 5th shows up on my calendar as a 3pm Twitter-hosted meeting, since
>> those have traditionally been "Monthly on the first Thursday". After
>> this, the other meetings (third Thursday, or every other week?) can
>> alternate between 9pm/9am. Let's get these on the calendar officially.
>>
>> Vinod, are you/Twitter still planning to host the community sync
>> tomorrow?
>>
>> On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon 
>> wrote:
>>
>>> We'll have the next community sync this Thursday (Oct. 15th) from
>>> 9-10am Pacific.
>>>
>>> Please add items to the agenda
>>> 
>>> .
>>>
>>>
>>> We will use Hangouts on Air again. We will post the video stream link
>>> shortly before the meeting, and only active participants (especially people
>>> on the agenda) should join the actual hangout. Others can watch the video
>>> stream and ask brief questions on #mesos on IRC. If you have something
>>> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
>>> into the hangout.
>>>
>>> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
>>> reception on the 2nd floor.
>>>
>>>
>>> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>>>
 Got it. Thank you.

 On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
 wrote:

 > Yes, community sync is at 3 pm PST today afternoon. Video Link is
 still not
 > available. And here is the link for meeting agenda/notes:
 >
 >
 >
 https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
 >
 > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
 >
 > > Do today have community sync?
 > >
 > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon 
 > > wrote:
 > >
 > > > Today's community sync video/audio is archived at:
 > > > http://youtu.be/ZQT6-fw8Ito
 > > > The meeting agenda/notes are available at:
 > > >
 > > >
 > >
 >
 https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
 > > >
 > > > For convenience, today's notes are reproduced below:
 > > >
 > > >-
 > > >
 > > >0.21.2-0.24.1 Patch Releases [Adam]
 > > >-
 > > >
 > > >   What’s the plan for how many releases we want to support?
 BenH:
 > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x)
 for
 > > > which we will
 > > >   do patch fixes
 > > >   Neil: Or support an LTS version + recent releases
 > > >   -
 > > >
 > > >   Separate Release Manager for backports? Joris and MPark
 will RM
 > for
 > > >   these patch releases, with Adam shepherding. In general,
 > > patch/point
 > > >   releases don’t need to be managed by the same person who
 did the
 > > > original
 > > >   release.
 > > >   -
 > > >
 > > >   Need some guidelines (on the website) for what is a
 > > >   backport-able/critical patch.
 > > >   -
 > > >
 > > >   AI[Adam+0.25RMs]: Expand Release Guide with # supported
 releases,
 > > >   guidelines for critical patches, RM roles/responsibilities
 > > >   -
 > > >
 > > >0.25.0 Release Planning[Joris]: Dashboard
 > > ><
 > > >
 > >
 >
 https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326859
 > > > >
 > > >-
 > > >
 > > >   Planning a triage meeting for Friday, hope to cut
 0.25.0-rc1 by
 > > Sept.
 > > >   23rd.
 > > >   -
 > > >
 > > >MesosCon EU [Adam]: Schedule announced!
 > > > http://mesosconeu2015.sched.org/
 > > >-
 > > >
 > > >   Register! Attend! Meet cool people! Learn awesome things!
 > > >   -
 > > >
 > > >   Want to grow developer community as well as user community
 > > >   -
 > > >
 > > >   Community voting vs. Program Committee selection?
 > > >   -
 > > >
 > > >Mesos Developer 

Proposal: move towards #pragma and away from #include guards

[Alex Clemmer]

Hey folks.

In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
brought up the issue of moving away from #include guards and towards
`#pragma once`.

As this has been brought up before, I will be brief: we think it's
revisiting because the primary objection in previous threads appears
to be that, though `#pragma once` is a cleaner solution to the
multiple-include problem, it's not so much better that it's worth the
code churn. However, the ongoing Windows integration work means we
have to touch these files anyway, so if we agree this is cleaner and
desirable, then this is an opportunity to obtain that additional code
clarity, without the cost of the churn.

For the remainder of the email, I will summarize the history of our
discussion of this issue, who will do the work, and what the next
steps are.

PROPOSAL: We propose that all new code use `#pragma once` instead of
#include guards; for existing files, we propose that you change
#include guards when you touch them.

HISTORY: This has been discussed before, most recently a year ago on
the mailing list[2]. There is a relevant JIRA[3] and discarded
review[4] that changes style guide's recommendation on the matter.

SUMMARIZED OBJECTIONS:
1. The Google style guide explicitly forbids `#pragma once`.
2. This results in a lot of code churn, but is only marginally better.
3. It's not C++ standardized/it's platform dependent/IBM's compiler
doesn't support it.
4. Popular projects like Chrome don't do `#pragma once` because of
history clutter.
5. Intermediate state of inconsistency as we transition to `#pragma
once` from #include guards.

OUR RESPONSE:
Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
points out in a previous thread that the Google style guide was
canonized when `#pragma once` was Windows-only, and the guidance has
not changed since because of the history churn problem. As noted
above, we think the history churn problem is minimized by the fact
that it can be wrapped up into the Windows integration work.

For objection (3), the consensus seems to be that the vast majority of
compilers we care about (in particular, the ones supporting C++ 11) do
support it.

For objection (5) we believe the inconsistent state is likely to not
be long lived, as long as we commit to wrapping this work up into the
Windows integration work.

SUMMARIZED ADVANTAGES:
* Basically fool-proof. Communicates simply what its function is (you
include this file once). Semantically it is "the right tool for the
job".
* No need for namespacing conventions for #include guards.
* No conflicts with reserved identifiers[5].
* No internal conflicts between include guards in Stout, Process
library, and Mesos (this is one reason we need the namespacing
conventions)
* Reduces preprocessor definition clutter (we should rely on #define
as little as humanly possible).
* Optimized to be easy to read and reason about.

NEXT STEPS:
If we agree that this is the right thing to do, committers would ask
people to use `#pragma once` for new code when presented in code
reviews. For files that exist, I will take point on transitioning as
we complete the Windows integration work. I expect this work to
completely land before the new year.


Thanks,


[1] https://reviews.apache.org/r/39803/
[2] https://www.marc.info/?t=142540100400015=1=2
[3] https://issues.apache.org/jira/browse/MESOS-2211
[4] https://reviews.apache.org/r/30100/
[5] 
http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier


-- 
Alex

Theory is the first term in the Taylor series of practice. -- Thomas M
Cover (1992)

Re: Backticks in comments

[Bernd Mathiske]

+1

> On Nov 2, 2015, at 8:34 PM, Isabel Jimenez  
> wrote:
> 
> +1 for backticks, same comment as Kapil, really nice to be able to make a
> difference from string literals.
> 
> On Mon, Nov 2, 2015 at 11:26 AM, Kapil Arya  wrote:
> 
>> +1 for backticks. Also allows us to differentiate ordinary string literals
>> like names, etc., from code.
>> 
>> On Mon, Nov 2, 2015 at 2:18 PM, Marco Massenzio 
>> wrote:
>> 
>>> +1
>>> 
>>> I much favor using backticks everywhere for consistency, since (as you
>>> correctly pointed out) our Doxygen style requires that.
>>> Hopefully, over time, we will have the whole codebase consistent again
>>> (also an invite to folks, if you touch the code, to update comments
>>> accordingly).
>>> 
>>> BTW - unfortunately, Jira's markdown does not support backticks IIRC, but
>>> {{ }} to demarcate 'fixed font' in paragraphs (and {code} or {noformat}
>>> blocks for code snippets).
>>> 
>>> (RB uses "generally-accepted" markdown, though, so that's good!)
>>> 
>>> Thanks for raising awareness about this, Greg!
>>> 
>>> --
>>> *Marco Massenzio*
>>> Distributed Systems Engineer
>>> http://codetrips.com
>>> 
>>> On Mon, Nov 2, 2015 at 10:38 AM, Alex Clemmer <
>> clemmer.alexan...@gmail.com
 
>>> wrote:
>>> 
 +1. Additional note is that this is now the de facto syntax for code
 snippets on the rest of our tools, too, including RB and JIRA.
 
 On Mon, Nov 2, 2015 at 10:32 AM, Greg Mann  wrote:
> Hey folks!
> I wanted to bring up a style issue that I noticed recently. In some
> comments in the codebase, backticks are used to quote code excerpts
>> and
> object names, while in other comments, single quotes are used. This
 doesn't
> seem to be documented in our style guide (nor in Google's), and I
>> think
 it
> would be a good idea to establish a policy on this and document it,
>> so
 that
> we can avoid wasted review cycles related to this in the future.
> 
> It's likely that the backtick convention began because Doxygen will
 render
> backtick-enclosed text in monospace, and for this reason I would
>>> propose
> that we consistently use backticks to quote code excerpts and object
 names
> in comments from now on. What does everyone else think?
> 
> Cheers,
> Greg
 
 
 
 --
 Alex
 
 Theory is the first term in the Taylor series of practice. -- Thomas M
 Cover (1992)
 
>>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Backticks in comments

[haosdent]

+1 Backticks used in markdown widely.

On Wed, Nov 4, 2015 at 11:03 PM, Bernd Mathiske  wrote:

> +1
>
> > On Nov 2, 2015, at 8:34 PM, Isabel Jimenez <
> contact.isabeljime...@gmail.com> wrote:
> >
> > +1 for backticks, same comment as Kapil, really nice to be able to make a
> > difference from string literals.
> >
> > On Mon, Nov 2, 2015 at 11:26 AM, Kapil Arya  wrote:
> >
> >> +1 for backticks. Also allows us to differentiate ordinary string
> literals
> >> like names, etc., from code.
> >>
> >> On Mon, Nov 2, 2015 at 2:18 PM, Marco Massenzio 
> >> wrote:
> >>
> >>> +1
> >>>
> >>> I much favor using backticks everywhere for consistency, since (as you
> >>> correctly pointed out) our Doxygen style requires that.
> >>> Hopefully, over time, we will have the whole codebase consistent again
> >>> (also an invite to folks, if you touch the code, to update comments
> >>> accordingly).
> >>>
> >>> BTW - unfortunately, Jira's markdown does not support backticks IIRC,
> but
> >>> {{ }} to demarcate 'fixed font' in paragraphs (and {code} or {noformat}
> >>> blocks for code snippets).
> >>>
> >>> (RB uses "generally-accepted" markdown, though, so that's good!)
> >>>
> >>> Thanks for raising awareness about this, Greg!
> >>>
> >>> --
> >>> *Marco Massenzio*
> >>> Distributed Systems Engineer
> >>> http://codetrips.com
> >>>
> >>> On Mon, Nov 2, 2015 at 10:38 AM, Alex Clemmer <
> >> clemmer.alexan...@gmail.com
> 
> >>> wrote:
> >>>
>  +1. Additional note is that this is now the de facto syntax for code
>  snippets on the rest of our tools, too, including RB and JIRA.
> 
>  On Mon, Nov 2, 2015 at 10:32 AM, Greg Mann 
> wrote:
> > Hey folks!
> > I wanted to bring up a style issue that I noticed recently. In some
> > comments in the codebase, backticks are used to quote code excerpts
> >> and
> > object names, while in other comments, single quotes are used. This
>  doesn't
> > seem to be documented in our style guide (nor in Google's), and I
> >> think
>  it
> > would be a good idea to establish a policy on this and document it,
> >> so
>  that
> > we can avoid wasted review cycles related to this in the future.
> >
> > It's likely that the backtick convention began because Doxygen will
>  render
> > backtick-enclosed text in monospace, and for this reason I would
> >>> propose
> > that we consistently use backticks to quote code excerpts and object
>  names
> > in comments from now on. What does everyone else think?
> >
> > Cheers,
> > Greg
> 
> 
> 
>  --
>  Alex
> 
>  Theory is the first term in the Taylor series of practice. -- Thomas M
>  Cover (1992)
> 
> >>>
> >>
>
>


-- 
Best Regards,
Haosdent Huang