wow, no. I was aware of dpark but I was unaware that they had rolled their
own driver. Interesting.
On Wed, Jul 23, 2014 at 11:17 AM, Tom Arnfeld wrote:
> Did anyone know this existed
> https://github.com/douban/dpark/tree/master/dpark/pymesos ? Just came
> across that while googling...
>
>
> On 23 July 2014 18:28, Erik Erlandson wrote:
>
>>
>>
>> - Original Message -
>> > -1 for git submodules. I am really not keen on those; worked with them
>> > while working on Chromium and it was, to be frank, a mess to handle,
>> update
>> > and maintain.
>> >
>>
>> I've also found submodules disappointing, and been watching on the
>> sidelines as the boost community discovers what a pita they are.
>>
>> A newer alternative is git subtree. Full disclosure: I haven't actually
>> worked with subtree, but it looks like a better system than submodules:
>>
>> http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
>>
>>
>>
>> > I am rooting for separate repos. Maybe worth a non-binding vote?
>> >
>> > Niklas
>> >
>> >
>> > On 17 July 2014 11:45, Tim St Clair wrote:
>> >
>> > > Inline -
>> > >
>> > > --
>> > >
>> > > *From: *"Vladimir Vivien"
>> > > *To: *user@mesos.apache.org
>> > > *Sent: *Tuesday, July 15, 2014 1:34:37 PM
>> > >
>> > > *Subject: *Re: Mesos language bindings in the wild
>> > >
>> > > Hi all,
>> > > Apologies for being super late to this thread. To answer Niklas
>> point at
>> > > the start of the thread: Yes, I am thrilled to contribute in anyway I
>> can.
>> > > The project is moving forward and making progress (slower than I
>> want, but
>> > > progress regardless).
>> > >
>> > > Going Native
>> > > Implementing a native client for Mesos is an arduous process right now
>> > > since there's little doc to guide developers. Once I went through
>> C++ code
>> > > and a few emails, it became easy (even easier than I thought). If
>> the push
>> > > is for more native client, at some point we will need basic internals
>> to be
>> > > documented.
>> > >
>> > > Mesos-Certified
>> > > Maybe a Mesos test suite can be used to certify native clients.
>> There are
>> > > tons of unit tests in the code that already validate the source code.
>> > > Maybe some of those test logic can be pulled out / copied into a
>> small
>> > > stand-alone mesos test server that clients can communicate with to
>> run a
>> > > test suite (just an idea). This along with some documentation would
>> help
>> > > with quality of native clients.
>> > >
>> > >
>> > > +1.
>> > >
>> > >
>> > > In or Out of Core
>> > > Having native clients source hosted in core would be great since all
>> code
>> > > would be in one location. Go code can certainly co-exist a subproject
>> in
>> > > Mesos. Go's build workflow can be driven by Make. Go's dependency
>> > > management can work with repo subdirectories (at least according to
>> 'go
>> > > help importpath', I haven't tested that myself). But, as Tom pointed
>> out,
>> > > the thing that raises a flag for me is project velocity. If author
>> wants
>> > > to move faster or slower than Mesos release cycles, there's no way to
>> do so
>> > > once the code is part of core.
>> > >
>> > > Anyway, I have gone on long enough. Looking for ward to feedback.
>> > >
>> > >
>> > > I usually don't tread here, but perhaps a git-submodule works in this
>> > > narrow case.
>> > > Thoughts?
>> > >
>> > >
>> > >
>> > > On Tue, Jul 15, 2014 at 10:07 AM, Tim St Clair
>> > > wrote:
>> > >
>> > >> Tom -
>> > >>
>> > >> I understand the desire to create bindings outside the core. The
>> point I
>> > >> was trying to make earlier around version semantics and testing was
>> to
>> > >> 'Hedge' the risk. It basically creates a contract between core &
>> > >> framework+bindings writers.
>> > >>
>> > >> No one ever intends to break compatibility, but it happens all the
>> time
>> > >> and usually in some very subtle ways at first. A great example of
>> this is
>> > >> a patch I recently submitted to Mesos where the cgroup code was
>> writing an
>> > >> extra <> this,
>> > >> but recent modifications would cause the cgroup code to fail. Very
>> > >> subtle,
>> > >> and boom-goes-the-dynamite.
>> > >>
>> > >> Below was an email I sent a while back, that outlines a possible
>> > >> hedge/contract. Please let me know what you think.
>> > >>
>> > >> --
>> > >> >
>> > >> > Greetings!
>> > >> >
>> > >> > I've conversed with folks about the idea of having a more
>> formalized
>> > >> release
>> > >> > and branching strategy, such that others who are downstream can
>> rely on
>> > >> > certain version semantics when planning upgrades, etc. This
>> becomes
>> > >> doubly
>> > >> > important as we start to trend towards a 1.0 release, and folks
>> will
>> > >> depend
>> > >> > heavily on it for their core infrastructure, and APIs (Frameworks,
>> and
>> > >> EC).
>> > >> >
>> > >> > Therefore, I wanted to propose a more formalized br
