Re: Continuous integration for skribilo

[Jonathan McHugh]

November 11, 2021 5:26 AM, "Arun Isaac" <arunisaac@systemreboot.net> wrote:

> 
>> Such an approach could help alleviate or complement interfacing issues
>> concerning hooks (if not reduce CI's environmental footprint if people
>> were to commit to being the next builder (a CI builer queue?)).
> 
> I don't know how to ensure availability without some trust among the
> peers servicing the queue. Besides, how is the environmental footprint
> lower if the builds are distributed among different peers? In both
> setups, there's still one build happening somewhere in the world.
>

I meant it in terms of people duplicating test builds. If there is a new 
upstream release that does not compile to Guix then N number of people may 
attempt to build it, resulting in N duplications. Of course, there are enough 
seasoned programmers with their own forks which make this redundant.

I have in the past ruminated on an individualist package management workflow - 
based upon feedback individual peers (or collective thresholds) updating 
specific infrastructure, rather than the aggregate community package management 
lists perse. Your Laminar example gives an aperture regarding how this may 
become actionable.

I hope Im a little clearer..., If I say any more Ludo may moderate me for being 
off topic (HA!).


Jonathan