Re: js-inbound as a separate tree

2013-12-21 Thread Chris Peterson
On 12/19/13, 4:20 PM, David Burns wrote: I know that RelEng are looking into how to do scheduling better, I am not sure where they are with this or if it is started but its a good first step. The whole "a push can take hours to build/test" is the thing that we need to be pushing against. I think

Re: js-inbound as a separate tree

2013-12-19 Thread David Burns
On 19/12/2013 23:56, Jason Orendorff wrote: On 12/19/13 4:55 PM, David Burns wrote: On 19/12/2013 18:48, Jason Orendorff wrote: Con: - more work for sheriffs (mostly merges) If mostly merges, are you suggesting there will be little traffic on the branch or the JS team will watch the tree for f

Re: js-inbound as a separate tree

2013-12-19 Thread Jason Orendorff
On 12/19/13 4:55 PM, David Burns wrote: > On 19/12/2013 18:48, Jason Orendorff wrote: >> Con: >> - more work for sheriffs (mostly merges) > > If mostly merges, are you suggesting there will be little traffic on > the branch or the JS team will watch the tree for failures? Neither, I'm just saying

Re: js-inbound as a separate tree

2013-12-19 Thread Bobby Holley
On Thu, Dec 19, 2013 at 2:53 PM, Jonathan Griffin wrote: > The disadvantage is that you may end up waiting to have your patch landed, > and some bugs may be hard for the sheriffs to land; e.g., if there are a > lot of patches in a single bug, and some of them have already landed, or > there are pa

Re: js-inbound as a separate tree

2013-12-19 Thread David Burns
Personally I find the branches we have annoying and are papering over the real problem that our feedback cycles once landed are far too long. Just for that reason alone I am against the idea. I think if we can solve the build/test scheduling and being smart about how we do our testing we can r

Re: js-inbound as a separate tree

2013-12-19 Thread Jonathan Griffin
We already have the approximate equivalent of this. It's the 'checkin-needed' keyword. Add this to your bug, and the sheriffs will land the patch for you, using the approximate process you describe. The only difference is this is done out-of-band, so turnaround may take up to 24 hrs. The a

Re: js-inbound as a separate tree

2013-12-19 Thread Bobby Holley
As someone who works mostly on the intersection of the JS engine and everything else, I'm not really wild about this. SpiderMonkey is pretty intimately tied to the rest of Gecko, certainly just as much as something like gfx. I think fx-team makes more sense, since most of the patches there consist

js-inbound as a separate tree

2013-12-19 Thread Jason Orendorff
On dev-tech-js-engine-internals, there's been some discussion about reviving a separate tree for JS engine development. The tradeoffs are like any other team-specific tree. Pro: - protect the rest of the project from closures and breakage due to JS patches - protect the JS team from closures and