Re: The new Buildbot: what’s happ ening, what needs to happen

Hi John,

Thanks for your feedback. Comments are inline.

On 2017-12-21 05:47, [email protected] wrote:
> * All compilers have been updated; the oldest is now GCC 4.9.1
>
> A lot of the older, but still supported, platforms on buildbot use older toolchains and for various reasons (2.4 kernels, ancient LibC's, hardware, weird SDK's etc.) are going to struggle to get up to that sort of level. 
> Nothing we have is in the old 2.95 type territory but if we are going to set a baseline for GCC we may have to drop some ports.
>
> That said, most of the compilers I use for my ports that are on older GCC's are either already in Docker containers or chroots so I'll have a go at packaging them up for this. I can't really see it being much of a problem and if we wanted to bump the minimum GCC that would be more of a project level decision anyway.

This is something I hope to discuss also in the near future. In the
interest of keeping things focused, in this thread I intend to remain
speaking on just what is happening with the new Buildbot stuff.

> * New packages are generated immediately upon successful build, instead of only once nightly
>
> Great. One thing I also added to my local hacks with this a year or so back was creating builds with --enable-release set on a weekly basis as an 'advanced user snapshot' in addition to the CI builds.

My experience over the last year indicates that a large proportion of
active ScummVM users are simply always running the latest nightly
builds, so since people are already using the nightlies like a rolling
release, we might as well support those users fully and make it so that
they’re getting builds which are going to perform as well as an official
release. The only concern I have is about how long it will take to
compile everything when that is the default. I’m not concerned about
debug builds, since if a user needs to get a debug build because
optimisations are making understanding a bug difficult, we have the
capability of manually generating those on-demand from the Buildbot now,
so I am leaning toward just enabling optimisations by default when an
automatic build is triggered.

> I can't say I agree with this. It raises the barrier to entry a fair bit. That said, it is not hard to get the containers working. My concerns are more around stuff that is just not going to work in this environment.

The questions that I would like to have answered in this case are, why
should the ScummVM team be adopting ports into the mainline which we
cannot even build? What is the argument for doing this, which is not
addressed by linking to unofficial ports on downloads and having a
simple policy of not making them official until we have the minimal
capability of building a binary for the platform? If we can’t even build
a new binary for a user to allow them to test if we’ve fixed a bug, how
can we possibly be expected to be responsible for anything to do with
such a port? How could we ever attempt to fix a bug and ask a user to
test if it’s fixed without being able to create a binary for them? How
can we state honestly to our users and to ourselves that we “officially”
support something which we are incapable of building, testing, or releasing?

I absolutely acknowledge that this policy raises the barrier for entry
into the “official ports” club. The alternatives that I see are that we
either can’t even work on all our “official” ports (which seems to
undermine the entire notion of anything being “official”), or we’re
forcing overburdened core team members to cobble together toolchains
after the original porter disappears, which just burns out the few
regular contributors the project has left.

Best,

-- 
Colin Snover
https://zetafleet.com


_______________________________________________
Scummvm-devel mailing list
[email protected]
http://lists.scummvm.org/listinfo/scummvm-devel