[LLVMdev] [Zorg] Reorganisation, documentation and other issues

[Dan Liew]

On 11 August 2014 19:07, Galina Kistanova <gkistanova at gmail.com> wrote:
> Hello everyone,
>
> Zorg is a common code for multiple different buildbot setups. This is why it
> sits in its own subtree.
> The only tricky thing there is that it assumes some relative position of
> zorg and master setup. Documenting this would save somebody some time.

When I have some time I'll look into it.

> All together wasn't a problem so far. But having a better documentation and
> a set of files for a simple local setup is a good idea. Patches are welcome.
> Otherwise it will wait till I have time for this.

When I find time I'll look into it.

>> * Buildbot should load slaves from a file not under version control for
>> local testing.
>
> I'm skeptical about pre-cooked dev buildbot/zorg setup. In any real case, a
> developer will need to modify the master to host a custom builder which is
> work in progress. The best we can do is preparing a consistent set of
> configuration files for a simple existing builder (just one), but all files
> should be under the version control. So one could be sure the setup is
> complete and could see the local changes he/she made and roll them back if
> desired.

I didn't explain myself clearly. The "list of builders" not being
under version control was a proposal for the localhost testing
configuration only.

> The rest is fine with me.
>
>> * reload()
>
> As Daniel mentioned, we are trying to apply as much changes as practical
> without restarting the production buildbot. Each restart is a disturbance.

As I mentioned to Daniel in an earlier e-mail. There already seems to
be code for this in zorg (reload_all in
zorg/buildbot/util/reloading.py) but the osuosl isn't using it which
is a little weird.

Mind if I change the osuosl code to use this and then clean up all the
uses of reload()?


>> * Ancient version of buildbot.
>
> We had problems with newer versions and we have a number of local changes
> and bug fixed which didn't make in 0.8 branch because the buildbot team
> considers them "too risky". The changes are pending for 0.9.
> The production is stable and working well, and I'm not aware of any cool
> feature we are missing on master. None of this changes is relevant for the
> "new builder development" case, only fr the production build master.

This was relevant for me because version 0.8.5 simply doesn't work on
my system (even inside a python virtualenv) without patching it. You
are obviously more aware of these build bot compatibility issues than
I am so perhaps the easiest thing to do is to note in the
documentation that you can use newer versions of build bot for
localhost testing and when they send patches for zorg to you, you will
discover if there any issues with the patch for 0.8.5.

<snip>

>> * llvmlab, osuosl, smooshlab?
>
> Reorganizing this currently is a work in progress. osuosl is in use; llvmlab
> is in use but will be decommissioned; smooshlab is used internally and is
> pending to be removed.

Daniel Dunbar suggested that smooshlab can just be removed for zorg.
Is it okay to go ahead and do that?

Thanks,
Dan.