Closed Bug 611670 Opened 14 years ago Closed 12 years ago

Drop the use of sendchange in favor of trigger, or equiv that keeps sourcestamp

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: Pike, Unassigned)

References

Details

(Whiteboard: [l10n][automation])

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.
Priority: -- → P4
No longer blocks: 614548
Component: Release Engineering → Release Engineering: Automation
Priority: P4 → --
QA Contact: release → catlee
Whiteboard: [l10n][automation]
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.
Blocks: 698910
If you have some concrete changes we can make, please open up a new bug at that point. Thanks!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.