Closed Bug 491378 Opened 16 years ago Closed 15 years ago

Try server doesn't try DEBUG builds

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 520227

People

(Reporter: cjones, Unassigned)

References

Details

Over the weekend, I submitted a patch that passed try with flying color, then broke Windows DEBUG builds in a stupid way. It'd be great if try could catch these errors.
Oops, should have told you the right component!
Component: Try Server → Release Engineering
Product: Webtools → mozilla.org
QA Contact: try-server → release
Version: Trunk → other
bsmedberg did, but I didn't believe him :). Just curious: what's the "try server" component for?
What's the desired outcome here: to have the try server attempt a debug build following a successful regular build? Given contention for the try server, I'm not sure if that's feasible.
I imagine it would be parity with the existing tinderboxen. That is to say: run debug builds in parallel with everything else. I agree with coop though, we don't have the resources to do it (yet).
(In reply to comment #5) > I imagine it would be parity with the existing tinderboxen. That is to say: run > debug builds in parallel with everything else. How do we reconcile that with the ability to use/submit a custom mozconfig?
(In reply to comment #4) > What's the desired outcome here: to have the try server attempt a debug build > following a successful regular build? > I'd prefer them to happen in parallel, but sequentially is OK. > Given contention for the try server, I'm not sure if that's feasible. This should really be a non-issue. I have a laptop you can borrow if you're low on machines.
(In reply to comment #6) > (In reply to comment #5) > > I imagine it would be parity with the existing tinderboxen. That is to say: run > > debug builds in parallel with everything else. > > How do we reconcile that with the ability to use/submit a custom mozconfig? If you have a custom config, you only get the custom build. Otherwise, opt and debug. (And we should encourage people to use custom configs.) Sound reasonable?
(In reply to comment #7) > > Given contention for the try server, I'm not sure if that's feasible. > > This should really be a non-issue. I have a laptop you can borrow if you're > low on machines. Um, contention is a real issue. See the mozilla.dev.tree-management newsgroup for daily reports on how swamped we currently are. Your laptop is not going to help, let's not trivialize the problem.
> > This should really be a non-issue. I have a laptop you can borrow if you're > > low on machines. > > Um, contention is a real issue. See the mozilla.dev.tree-management newsgroup > for daily reports on how swamped we currently are. Your laptop is not going to > help, let's not trivialize the problem. Sorry, this annoys me. If contention is a problem, MoCo should purchase 100 more machines. It's way more than worth it in terms of developer productivity. I don't see where the issue is.
(In reply to comment #10) > Sorry, this annoys me. If contention is a problem, MoCo should purchase 100 > more machines. It's way more than worth it in terms of developer productivity. > I don't see where the issue is. As Ben noted in comment #5, this *is* a parity issue. We are in the process of fixing it, we simply don't have the resources online yet. Machines don't just appear, and don't magically appear already setup. Moving to Future until machine are acquired/blockers are fixed.
Component: Release Engineering → Release Engineering: Future
Depends on: 488459, 488463, 488583
(In reply to comment #5) > I imagine it would be parity with the existing tinderboxen. That is to say: run > debug builds in parallel with everything else. Yeah, the closer the fidelity of the try server to the Firefox tinderbox, the better. In this specific case Chris ran a patch by the try server where it passed just fine, but it burned on the debug tinderbox when he landed it. I told him to file this bug for that reason, but I don't think it's a critical need, just something we should get when we have the resources to support it.
I'll grab this bug to make sure it doesn't get lost. This is blocked on at least getting more slaves & cleaning up the config - adjusting the deps as such.
Assignee: nobody → bhearsum
Depends on: 486567
Priority: -- → P3
Removing myself from this at joduinn's request.
Assignee: bhearsum → nobody
> > Given contention for the try server, I'm not sure if that's feasible. > > This should really be a non-issue. I have a laptop you can borrow if you're > low on machines. Hello readers of this bug, I apologize for this comment. Yesterday, for a variety of reasons, was one of the worst of the year for me and I was not in a good mood. This was a ridiculous and insulting way to discuss this important issue. After talking to John today, I can assure you we're very much on the same side. If there's any way I can help with bringing up machines faster, etc., please let me know. Until tryserver can build debug/opt and run all our unit tests, on all platforms, in an hour or so :), I will continue to be "annoyed." But hopefully from now on in a more constructive way. ;)
Breaking the Firefox tinderbox with patches that passed the try server is going to become a *lot* more common once we get DEBUG unit tests up and running (which I'm hoping is really soon). So I think this should be a pretty high priority to get this up and running -- in the same configuration that we'll be using for debug unit tests, hopefully.
(In reply to comment #16) > Breaking the Firefox tinderbox with patches that passed the try server is going > to become a *lot* more common once we get DEBUG unit tests up and running > (which I'm hoping is really soon). So I think this should be a pretty high > priority to get this up and running -- in the same configuration that we'll be > using for debug unit tests, hopefully. No disagreement here, just waiting on the new machines. bhearsum's already working on the code cleanup in bug 486567.
Actually, once bug#520227 is done, you'd get this, and a bunch of other goodness. Not sure if I should mark this as DUP (of newer bug#520227 :-( I know) or leave it here and mark as blocked on bug#520227. cjones: any pref?
Sure, if it's subsumed, I like DUP.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.