wgrant | blr: How's it looking? | 04:59 |
---|---|---|
=== Spads_ is now known as Spads | ||
wgrant | cjwatson: Did you work out your team mail stuff? | 10:00 |
cjwatson | wgrant: No serious blockers but I got distracted by landing all the things yesterday. | 10:09 |
cjwatson | Hm. I just found RecipeBuildBehaviour._extraBuildArgs and config.builddmaster.bzr_builder_sources_list. I wonder if I should replace my tools_archive stuff with that? | 10:22 |
wgrant | Oh, I thought that had been removed. | 10:22 |
wgrant | Oops. | 10:22 |
wgrant | We haven't used it in years. | 10:22 |
cjwatson | tools_archive is in one way a bit more elegant, but it doesn't support specifying a different series, nor does it support specifying a sources.list somewhere that isn't the same LP instance. | 10:23 |
cjwatson | I assumed it had been removed ages ago and hadn't even looked; I only ran across it by accident | 10:23 |
cjwatson | I'm inclined to push the bzr_builder_sources_list stuff down to get_sources_list_for_building and remove tools_archive. It's basically the same as the deprecated OEM external dependencies stuff. | 10:26 |
cjwatson | Except per-build-behaviour rather than per-archive. | 10:27 |
wgrant | Right, sounds reasonable to me. | 10:27 |
wgrant | Sorry, I hadn't realised it was still around. | 10:27 |
cjwatson | NP | 10:27 |
cjwatson | RecipeBuildBehaviour puts it after the primary archive in sources.list, but I think just before (as tools_archive) is conceptually slightly better. | 10:28 |
wgrant | Agreed. | 10:28 |
cjwatson | Little difference in practice unless the same version ends up in the primary archive. | 10:29 |
wgrant | One day I am going to hack Zope to allow deep views. | 10:30 |
wgrant | +webhooks, +webhook/foo, +new-webhook | 10:30 |
wgrant | Madness | 10:30 |
cjwatson | wgrant: Your celery tests seem very unreliable in buildbot ... | 10:57 |
wgrant | cjwatson: Yes, I've relaxed the two unreliable ones in my latest branch. | 10:58 |
wgrant | buildbot really can be very slow at running code :( | 10:58 |
cjwatson | wgrant: Were you thinking that I should have a straight-through test that there's failure-counting if the snap source has been deleted, or is it enough to trust the general scan/scanFailed behaviour of builddmaster and check for the AssertionError on dispatch? | 11:35 |
wgrant | cjwatson: I think the latter is fine. | 11:36 |
wgrant | buildd-manager tests are awkward, and that behaviour is already reasonably well tested. | 11:36 |
cjwatson | Good, that's what I thought/hoped. | 11:38 |
wgrant | I'm not that cruel. | 11:38 |
cjwatson | Oh, fixing this will imply making branch/repository deletion hook into snaps, though. Which was on my to-do, just a bit further down. | 11:41 |
cjwatson | I guess it's not hard. | 11:41 |
wgrant | Ah, fair. | 11:42 |
wgrant | It's not a blocker for landing the branch. | 11:42 |
wgrant | But I'd quite like to have some assertion that the behaviour is sane so when we rework something in three years we don't burn alphecca down. | 11:42 |
cjwatson | I think I'll just propose a separate branch first to fix deletion. Easier that way round than some kind of weird assertion about what happens if a reference points into the void ... | 11:48 |
wgrant | Yep | 11:49 |
=== Guest47499 is now known as anthonyf | ||
=== anthonyf is now known as Guest410 | ||
=== Guest410 is now known as anthonyf | ||
=== anthonyf is now known as Guest26675 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!