The extensive use of sendchange makes our build status a confusing mess.
There shouldn't be anything in sendchange that we can't reproduce on top of scheduler db, hopefully. With http://buildbot.net/trac/ticket/1039, plain trigger should probably do it.
The dependent/triggered builds should keep the sourcestamp of the original build, as that's, for one, the right thing to do, and it will make reporting so easy that we don't need to restrict the build infrastructure to only change in ways that the reporting hacks wouldn't break. I.e., if our builds were organized such that the reporting on top just had to show what's there, we can improve our builds without worrying that the reporting would break, or how it would show today's and last week's builds.
This is something we've been thinking about for a while, so thanks for filing the bug! We could actually use Trigger/Triggerable right now, but it makes the configs a bit ugly since all the Triggerable schedulers have to be active on each master.
I'm not sure I understand all that you're saying about reporting...In some cases you would share the same sourcestamp, but I'm not sure if that's true across the board?
(In reply to comment #1)
> I'm not sure I understand all that you're saying about reporting...In some
> cases you would share the same sourcestamp, but I'm not sure if that's true
> across the board?
The only challenge I saw was determening the sourcestamp for triggered l10n nightlies. There are arguments in favor of using the en-US sourcestamp and against. Like, it makes all the nightlies report is probably both pro and con, depending on how you look at it.
Axel, does build 'builduid' property cover what you need here? This is created by the scheduler for the builds, and propagated down to tests, repacks, etc.
I don't have concrete ideas these days. This might impact what can be done with the web reporting for l10n builds, though, which is now bug 698910.
If you have some concrete changes we can make, please open up a new bug at that point. Thanks!