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

["Christiano F. Haesbaert" <haesbaert@xxxxxxxxxxxxx>]

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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel