TBPL job visibility policy - now documented

2013-03-26 Thread Ed Morley
(Please reply to dev.tree-management) Until now, the requirements for a new platform/test-suite to be shown in the default TBPL view have been scattered across many newsgroup discussions, bugs IRC conversations, which understandably leads to surprise when developers working on bringing a new

getter_AddRefs

2013-03-26 Thread Neil
Why does getter_AddRefsT have an operator nsISupports**? So far most of the uses I've found appear to be people enumerating an nsISimpleEnumerator directly into an nsCOMPtrT type, although the documented idl return value is nsISupports. Is this an acceptable paradigm? -- Warning: May contain

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Dave Townsend
This is awesome, thanks for writing this up, it's made me spot one more place where Jetpack is failing. Can we get some more definition around Runs on all trees that merge into mozilla-central? In particular I want to make that true for Jetpack but I don't know what all those trees are.

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Benjamin Smedberg
On 3/26/2013 12:07 PM, Dave Townsend wrote: This is awesome, thanks for writing this up, it's made me spot one more place where Jetpack is failing. Can we get some more definition around Runs on all trees that merge into mozilla-central? In particular I want to make that true for Jetpack but

Re: getter_AddRefs

2013-03-26 Thread Benjamin Smedberg
On 3/26/2013 10:16 AM, Neil wrote: Why does getter_AddRefsT have an operator nsISupports**? So far most of the uses I've found appear to be people enumerating an nsISimpleEnumerator directly into an nsCOMPtrT type, although the documented idl return value is nsISupports. Is this an acceptable

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Ben Hearsum
On 03/26/13 12:17 PM, Benjamin Smedberg wrote: On 3/26/2013 12:07 PM, Dave Townsend wrote: This is awesome, thanks for writing this up, it's made me spot one more place where Jetpack is failing. Can we get some more definition around Runs on all trees that merge into mozilla-central? In

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Dave Townsend
On 3/26/2013 9:17 AM, Benjamin Smedberg wrote: On 3/26/2013 12:07 PM, Dave Townsend wrote: This is awesome, thanks for writing this up, it's made me spot one more place where Jetpack is failing. Can we get some more definition around Runs on all trees that merge into mozilla-central? In

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Ryan VanderMeulen
On 3/26/2013 12:07 PM, Dave Townsend wrote: This is awesome, thanks for writing this up, it's made me spot one more place where Jetpack is failing. Can we get some more definition around Runs on all trees that merge into mozilla-central? In particular I want to make that true for Jetpack but I

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Ben Hearsum
On 03/26/13 12:20 PM, Dave Townsend wrote: On 3/26/2013 9:17 AM, Benjamin Smedberg wrote: On 3/26/2013 12:07 PM, Dave Townsend wrote: This is awesome, thanks for writing this up, it's made me spot one more place where Jetpack is failing. Can we get some more definition around Runs on all

Re: TBPL job visibility policy - now documented

2013-03-26 Thread Ed Morley
I've replied to the last few posts on dev.tree-management :-) https://lists.mozilla.org/listinfo/dev-tree-management https://groups.google.com/d/topic/mozilla.dev.tree-management/N8xmYtgVp74/discussion On 3/26/2013 7:10 AM, Ed Morley wrote: (Please reply to dev.tree-management)