Ricardo Wurmus <[email protected]> skribis:

> Sam Halliday <[email protected]> writes:
>
>> Ludovic Courtès <[email protected]> writes:

[...]

>>> Guix’s build daemon uses containers to perform isolated builds:
>>>
>>>   http://www.gnu.org/software/guix/manual/html_node/Features.html
>>
>> Interesting. I wonder if you wouldn't benefit from a docker / drone
>> network, just as a distribution mechanism for your own build farm. It
>> would be a shame to expend effort on that since it is somewhat something
>> of a solved problem (and purely a DevOps matter, not a user concern).
>
> Work is under way to distribute build artifacts over GNUnet.  Currently
> it is already possible to share build results over HTTP.  Ideally,
> package building is a distributed effort.  (We aren’t there yet.)

There’s also the offloading mechanism, which may be closer to what Sam
was mentioning:

  https://www.gnu.org/software/guix/manual/html_node/Daemon-Offload-Setup.html

>>>> * Issue tracker / comm channels
>>>>
>>>> Will you be continuing to use debbugs, savannah and mailing lists going
>>>> forward or would you consider moving to a modern community management
>>>> system like gitlab?
>>>
>>> I hear the appeal of GitLab and the like.  However, as was recently
>>> discussed on guix-devel, while I think we must find ways to improve our
>>> workflows (for instance, tracking patches is becoming tricky), I don’t
>>> see us moving to one of those web-based approaches for several reasons:
>>>
>>>   https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00429.html
>>
>> I've never used GitLab, but I understand that it is free software. The
>> thread above seems to suggest that it is proprietary.
>
> There are two variants AFAIU; the hosted GitLab service uses the
> proprietary version.

Right, gitlab.com runs “GitLab EE”, which is proprietary.

Thanks,
Ludo’.

Reply via email to