Re: Backticks in comments

+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

Backticks in comments

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

Re: [proposal] Exposing Multiple Isolated Disks to Frameworks

+1 on this. Great work guys. Volumes are a good start, but when we have users with large amounts of data, we need an API for storage to work seamlessly at the level within the band of Mesos (Disks or Multiple Disks should be offered as well as volumes). Storage drivers is also an important concept

Re: Backticks in comments

+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

Re: [proposal] Exposing Multiple Isolated Disks to Frameworks

I see 3 docs linked from MESOS-191 (and none in your email), but I assume you're talking about: https://docs.google.com/document/d/1syPxygVNEHjG6FoyqslnpUGgNpYKU9QzKBuV2yKmjfQ/edit#heading=h.4fzj9sl24cwy On Thu, Oct 29, 2015 at 1:00 PM, David Greenberg wrote: > Hello

Re: Backticks in comments

+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 -

Re: Backticks in comments

+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

Re: [proposal] Exposing Multiple Isolated Disks to Frameworks

Sorry for not directly linking! Yes, that is the doc. I'll update the ticket to include it in the description. On Thu, Oct 29, 2015 at 1:00 PM David Greenberg wrote: > Hello Everyone, > At the MesosCon Dublin Hackathon, we started working on MESOS-191. The > goal of this

Re: [Breaking bug fix] Binary in state endpoints

+1 to remove the field directly, one comment is that the upgrade document may need to be updated. >From my understanding, since the data is binary data and I did not see too much requirement on retrieving binary data. Thanks! On Sat, Oct 24, 2015 at 5:33 AM, Joseph Wu

Re: [Breaking bug fix] Binary in state endpoints

Why not base64 encode the field? We use that field in our frameworks, and some of our platform tools would benefit from being able to read that data. Base64 seems like a compromise with minimal complexity addition. It also removes the potential for parse errors, doesn't rule out future

Re: [Breaking bug fix] Binary in state endpoints

In that case, I rescind my objection. Memory use as a problem and labels as an alternative work fine. Thanks! On Mon, Nov 2, 2015 at 7:03 PM Benjamin Mahler wrote: > Sorry for the confusion, the motivation to remove 'data' is for memory > scalability reasons (the

Re: [Breaking bug fix] Binary in state endpoints

Sorry for the confusion, the motivation to remove 'data' is for memory scalability reasons (the ability to express binary fields is orthogonal and is not the reason to remove 'data'). We can get into a really bad state in large clusters if frameworks are putting non-trivial amounts of 'data' in