[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] ipv4 configuration overhauls & dhcp client adjustments

So I made the transfer, I'm ok with the centrality aspect, I think
this helps ensuring charrua-core keeps going if I lose interest/focus.
As long as the library itself is independent of Mirage I'm happy.

And I also get the Mirage badge.

On 4 November 2016 at 12:05, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 4 Nov 2016, at 10:59, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>> On 04/11/2016 10:51, Anil Madhavapeddy wrote:
>>> On 4 Nov 2016, at 10:45, Christiano F. Haesbaert <haesbaert@xxxxxxxxxxxxx> 
>>> wrote:
>>>> On 4 November 2016 at 00:16, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>> These changes have been merged! Thanks for all of you who helped out,
>>>>> particularly Drup and Hannes who provided a lot of helpful code review and
>>>>> feedback.  Also, many thanks to haesbaert, as charrua-core was a dream to
>>>>> work with -- charrua-client is very small, and over half of it is tests. 
>>>>> :)
>>>> Oh that made my day \o/.
>>>> Would you like to merge that into charrua-core ?
>>>> I can give you commit access too.
>>>> I've been wanting to rename charrua-core to charrua-dhcp, then it could 
>>>> provide
>>>> both Dhcp_server and Dhcp_client.
>>> Should we perhaps also move the Charrua repos under the mirage/ org and 
>>> give you
>>> all access there? This keeps the dependent cluster of protocol libraries in 
>>> one
>>> place.
>> To jump in here: moving everything to a single organisation on GitHub
>> might seem to be a good idea at first sight: new people might be able to
>> more easily find active projects... but I don't think this is true at
>> all, browsing a GitHub organisation with >100 repositories (of unknown
>> state) is tedious.
> I think project discovery should be decoupled from the administrative
> process. There's a lot of utility in retaining the ability to group related
> repositories into one place, particularly those core to the project.
> People naturally come and go as their time permits, but keeping an
> authoritative copy of the code in one place is the purpose of the
> organisation. This then leaves people with the freedom to have their
> person accounts be places where they can rearrange and organise
> their code as they see fit, rather than have it be a core dependency
> on a bigger project.
>> Since TravisCI limits to 5 instances per organisation, there shouldn't
>> be any incentive to centralise the libraries.
>> And I still believe we need a dashboard and push forward with opam tags
>> to get an overview of active libraries -- http://docs.mirage.io is a
>> good first step in that direction.
>> Maybe there should be a MirageOS unikernel gallery as well (since for
>> some reason unikernels are not managed by opam (yet?)),
> These are all things that need to (and will) happen, but not a reason to block
> keeping our core networking libraries under one organisation right now :)
> Anil
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.