[Scummvm-devel] The new Buildbot: what’s happening, what needs to happen
Travis Howell
kirben at optusnet.com.au
Thu Dec 21 23:42:31 CET 2017
On 21/12/2017 6:58 PM, Colin Snover wrote:
> On 2017-12-20 21:26, Travis Howell wrote:
>> I really need to clarify this point, Eugene asked via email whether I
>> could provide a Windows build with WinSparkle support for ScummVM
>> 1.9.0. I responded quickly that another developer would be required
>> for WinSparkle support, since I disagreed with pushing untested
>> updates, and MinGW lacked the required API support for compiling
>> WinSparkle at the time. As usual I get no response at all, and only
>> see complaints on IRC later. I confirmed the compilation guide for
>> MinGW still worked at the time, other than a broken link or two. The
>> requested Windows build for Windows 9x/ME I provided (still online at
>> https://drive.google.com/open?id=0B7wJOP5u3deTRi0wZ2RNTzAwNkU ), was
>> never even added to the web site either.
>
> I can validate that it can be very frustrating when people don’t respond
> to questions or comments, and, I don’t currently understand how this
> clarification addresses my argument regarding the need for a policy
> requiring worker images for ports. You made a totally valid personal
> decision not to continue to create Windows release builds because you
> disagreed with the use of Sparkle, which you are completely entitled to
> do, and that decision did mean that extra work had to be done for the
> release because there was no pre-existing compilation environment image
> for Windows for another person to take over with. If there had been a
> policy requiring an image at that time, it would have been trivial
> another team member to continue Windows releases after the team decided
> that it was better on balance for users to enable automatic updates.
> Instead, this toolchain had to be rebuilt by another team member at
> their own expense. To me, this clearly demonstrates a benefit that such
> a policy would have in the future to ensure the continuity of our builds.
I will make this as brief as possible, to avoid going further off topic,
and no response is required:
The problems offering an alternative Windows build for ScummVM 1.9.0
were due to suddenly switching to a completely different compilation
environment (mingw-w64), which lacked any maintainer. I warned that
mingw-w64 support would require a separate maintainer, when initially
added to the ScummVM wiki.
A Buildbot mirror of my compilation environment would not have helped,
due to the lack of support in MinGW for the APIs used by WinSparkle at
the time.
>> I could have easily continued to provide working Windows release
>> binaries, if people would were more interested in providing a stable
>> release build, rather than pushing untested updates to people.
>>
>> I still think using buildbot for release builds is a bad idea in
>> general, unless the build environment on buildbot matches the build
>> environment used by the porter exactly. Otherwise there is the chance
>> of problems due to different compiler parts been used, especially in
>> the case of cross-compilation. It has happened a few times in the past
>> with the Windows port, due to those differences.
>
> I understand my original email was long, and I would encourage you to
> please read through all of it if you are interested in continuing to
> provide feedback in this thread, as I did explain that the goal here is
> to automate the releases, and that the new Buildbot worker images are
> identical to the “build environment used by the porter” as they *are* to
> be the build environments created and used by the porters.
Identical compilation environments been required for ScummVM porters on
the new Buildbot was not clear in your initial message, and is very good
to hear. That should avoid all the issues that have previously occurred
from minor differences.
If the new Buildbot compilation environments can be kept identical over
the long term, and testing is based only from those Buildbot builds, it
sounds like it should be safe enough, compared to manual releases.
The Windows port of ScummVM 2.0.0 was more risk this time around, due to
testing been based only off my Windows snapshots, and the final release
version been based off an updated Buildbot, that had no outside testing.
Hopefully that use of multiple compilation environments will never be
required again.
More information about the Scummvm-devel
mailing list