[Scummvm-devel] The new Buildbot: what’s happening, what needs to happen
Colin Snover
scummvm-devel at zetafleet.com
Thu Dec 21 20:34:14 CET 2017
Hi Marcus,
Thank you for your feedback. Comments are inline.
On 2017-12-21 04:48, Marcus Comstedt wrote:
> Hi,
>
> Tarek Soliman <tsoliman at scummvm.org> writes:
>
>> - Those docker images can be run anywere, including on the local development
>> machine.
> Um, no.
I would appreciate it if you would please use a more respectful tone
when communicating regarding these issues, so everyone feels safe and
welcome to participate in the discussion.
> To start with, AFAICT the images are built for x86 only. Sure, given
> the Dockerfile I could rebuild it for aarch64 or ppc64le, but even so
> Docker supports only a small set of platforms and architectures. If I
> wanted to build on say Linux/ppc64 (big endian) or Solaris/SPARC I'd
> be SOL. And as a matter of fact I _do_ make my ScummVM builds for
> Dreamcast on Solaris/SPARC; my T2 has 64 hardware threads and so is
> well suited for compiling stuff.
I understand that Docker is not going to be available for every possible
host platform, and, one of the most important ideas here is that no
person would be performing manual compilation of ScummVM, except during
development or updating of the worker images, so it would not be
relevant in the future that you have historically used a non-x86_64
platform for building these releases as humans would no longer be
responsible for building the official releases in this manner. If you do
not have an x86_64 computer, I would be happy to find you an inexpensive
used one so you may use the prebuilt images from Docker Hub, if you have
a concern about some difference between GCC running on platform X versus
on x86_64.
> > 3. Porters do stuff which is totally undocumented, like the Nero images
> > which are currently being created for the Dreamcast port.
> Unfortunately this is also something that requires manual attention
> for each release, so while documentation would probably be a good
> thing, trying to hide it behind automation is not going to work.
If you believe that there is a need to hand-split and add curated demos,
then simply update the Dockerfile and/or buildbot.cfg for the Dreamcast
worker with these changes whenever it is time to adjust the split or the
demos. Then the automated builder is up-to-date and the release process
can continue to be fully automated and maintained by other team members
whenever you are no longer available to do so. There is no need to make
an exception for a manual release process for this kind of thing.
Best,
--
Colin Snover
https://zetafleet.com
More information about the Scummvm-devel
mailing list