<div dir="ltr"><div dir="ltr">Hi all,</div><div dir="ltr"><br></div><div dir="ltr">I've got an iMac Pro in my LAN with 16 vCores and 64GB or RAM which is quite often idle.</div><div>I'm not privy with how our build system work, but if we could get to a point where agents can be added, stopped, throttled, trusted members of our community could volunteer the computational power they have at their disposal without fully dedicating a machine.</div><div>In my specific case: I'm happy to offer VMs on that machine to volunteer computational resources.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 19, 2021 at 7:38 PM Andrew Janke <<a href="mailto:floss@apjanke.net">floss@apjanke.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
I have a small stack of Mac Minis I got to use as a buildbot farm
for Octave.app; I might be able to have them pull double duty for
MacPorts depending on your change volume.<br>
<br>
Cheers,<br>
Andrew<br>
<br>
<div>On 5/19/21 1:16 PM, Mark Anderson
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Yeah - we are certainly short staffed everywhere - I try to
add more and more of my time to the project but aside from my
ports, I'm still in learning mode digging through all the
asciidoc and tcl and everything. I'm trying to build some
tools to help me, but again, more time.</div>
<div><br>
</div>
<div>Once we move to the latest build bot, we might want to see
if we can get other volunteers to host some hardware, but the
problem is, we're going to have to hit up ebay or something
and the infrastructure will be tougher.</div>
<div><br>
</div>
<div>I'm honestly not sure how we can manage to staff up more at
all - I mean this is a FOSS problem all over for non-company
sponsored projects.</div>
<div><br>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>—Mark<br>
</div>
<div>_______________________<br>
Mark E. Anderson <<a href="mailto:mark@macports.org" target="_blank">mark@macports.org</a>><br>
</div>
<div><a href="https://trac.macports.org/wiki/mark" target="_blank">MacPorts Trac
WikiPage</a><br>
</div>
<div><a href="https://github.com/markemer" target="_blank">GitHub Profile</a><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, May 18, 2021 at 2:35
AM Ryan Schmidt <<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">MacPorts
is short-staffed in all areas, not just infrastructure.<br>
<br>
Our Buildbot system works. It produces all the binaries we are
able to.<br>
<br>
Our buildbot system was already substantially redesigned when
we took it over from Apple in 2016 and will be substantially
redesigned again as we upgrade to the latest version of the
buildbot software.<br>
<br>
We already have a small infrastructure team who are interested
in working on improving the buildbot system and our other
infrastructure, and do so.<br>
<br>
We already use GitHub Actions for CI. We cannot use it to
replace buildbot because it only offers recent OS versions and
because it does not offer persistent machines.<br>
<br>
I personally am not comfortable adding other build machines to
our buildbot system that I do not control. When I control the
machines, I know what is installed on them and that they are
set up correctly. Having build machines located outside of my
local network also poses additional challenges, as I've
learned by having our Apple Silicon build machine outside of
my network, challenges which I would prefer to minimize, not
increase.<br>
<br>
We currently use one build machine per OS version / arch, and
have the hardware needed to do that. Adding more hardware such
that we have more than one build machine per OS version / arch
is not something our buildbot system was ever designed to
accommodate, and would introduce problems.<br>
<br>
Using Linux and commodity hardware is not applicable because
it the macOS EULA only permits running macOS on Apple
hardware, as we currently do.</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>