Now that there's an x86-64 box on the main tinderbox, there needs to be one on the try server pool as well, or the try server's go/no-go can't be trusted.
Understand this is useful, but lower priority then other work right now. Triaged to future.
Component: Release Engineering → Release Engineering: Future
Priority: -- → P3
Summary: Add linux x86-64 try server → Add linux x86-64 slave to try server
Ping.. we still have x86-64 on the main tinderbox, and I notice that we're publishing x86-64 nightlies as well. We need coverage for this on the try server..
I just claimed bug 530374 was ready to go, and tricked someone into burning the tree, based on not having x86-64 on the try server.
... it's been 1.5 years now, is it the future yet?
(In reply to comment #4) > ... it's been 1.5 years now, is it the future yet? Actually, the future was being worked on over in another bug. 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? Vlad: any pref?
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Once again, we either need to fix this, or get rid of the linux x86-64 machine from the main Firefox tinderbox tree. Last activity on the bug that this apparently depends on was a month ago. I don't know how more clear I can be: without an x86-64 slave on the try server, the try server is largely useless as a way to gain confidence that patches will not cause burning or other problems on the main tinderbox.
(Note also that at some point we had a decision that we would not put any platforms on the main tinderbox without accompanying try server coverage, especially if they are platforms that developers are not likely to have. That seems to have been ignored in this case. I understand the value of having a 64-bit tinderbox, so removing it does not seem like the right thing to do, but random 64-bit related burnings because of not being able to test a simple patch also should not be the status quo for almost 2 years.)
9 years ago
9 years ago
Whiteboard: [linux64] → [linux64][tryserver]
(In reply to comment #8) > (Note also that at some point we had a decision that we would not put any > platforms on the main tinderbox without accompanying try server coverage, > especially if they are platforms that developers are not likely to have. That > seems to have been ignored in this case. I understand the value of having a > 64-bit tinderbox, so removing it does not seem like the right thing to do, but > random 64-bit related burnings because of not being able to test a simple patch > also should not be the status quo for almost 2 years.) You're right, of course. Adding capacity to the try server for new ref platforms wasn't part of our checklist. The checklist has been fixed so we shouldn't have this problem going forward (Android, Win7 64-bit), but we'll need to scramble to get this support in place for Linux64 and 10.6 64-bit. Armen: can you take this bug since you've been doing the other Linux64 releng work?
My hope was that the bug of adding try server as a branch was going to happen imminently and that is why I added that dependency. We are obviously not even close. We need to add Linux 64 VMs to the try server meanwhile to get this going. I will work on getting these VMs without depending on that bug.
Assignee: nobody → armenzg
Reversing block/dependency. We are blocked on IT getting us few VMs for this.
Marking as dupe since we have a bug tracking the allocation of 64bit linux slaves to the try-as-branch that will be rolled out in the next couple of weeks. We will have 64 bit linux builds almost immediately since we have the hardware being imaged right now.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 550086
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.