mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominic Hamon <dha...@twopensource.com>
Subject Re: Usage of Mesos GitHub org for community plugins and modules
Date Fri, 19 Dec 2014 19:13:49 GMT
That's going to cause issues for any companies that use existing github
orgs and have internal restrictions on how they can share their open source
work.

On Fri, Dec 19, 2014 at 11:07 AM, Dave Lester <davelester@gmail.com> wrote:
>
> I'd suggest making the GH org home to community frameworks/modules.
>
> On Fri, Dec 19, 2014 at 11:04 AM, Dominic Hamon <dhamon@twopensource.com>
> wrote:
>
>> I think this is a reasonable start, but I'm not sure if you're suggesting
>> we make the mesos org the home for the community frameworks/modules, or
>> that we will maintain forks of those frameworks and modules in the mesos
>> org.
>>
>> On Fri, Dec 19, 2014 at 10:17 AM, Dave Lester <davelester@gmail.com>
>> wrote:
>>>
>>> Hi All,
>>>
>>> To push forward one portion of the conversation re: Mesos extension
>>> hosting
>>> and a shared registry (MESOS-1759
>>> <https://issues.apache.org/jira/browse/MESOS-1759>), I'd like to suggest
>>> that we begin using the existing Mesos GitHub org (
>>> https://github.com/mesos/)
>>> for community frameworks and modules. This is already happening in
>>> practice
>>> (see: mesos-go bindings, storm, hadoop + others already w/in the org),
>>> however I don't think this has explicitly been called out as an
>>> opportunity
>>> for folks to use.
>>>
>>> IMHO, opening this up to all is a good idea. I'd also recommend
>>> explicitly
>>> calling out the fact that while these projects are w/in the Mesos org on
>>> GH, they are not explicitly Apache projects. Any objections or
>>> suggestions?
>>>
>>> If this sounds good, I can add related documentation.
>>>
>>> Dave
>>>
>>
>>
>> --
>> Dominic Hamon | @mrdo | Twitter
>> *There are no bad ideas; only good ideas that go horribly wrong.*
>>
>
>

-- 
Dominic Hamon | @mrdo | Twitter
*There are no bad ideas; only good ideas that go horribly wrong.*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message