<div dir="ltr">On Thu, Apr 4, 2013 at 2:41 AM, David Rajchenbach-Teller <span dir="ltr"><<a href="mailto:dteller@mozilla.com" target="_blank">dteller@mozilla.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 4/4/13 12:05 AM, Dave Townsend wrote:<br>
>     I will try not to elaborate on the individual points of my previous<br>
>     e-mail, and rather to focus on the main point.<br>
><br>
>     Is there a strong reason to require that Promise, which has become a<br>
>     core toolkit module (or a core dependency of the toolkit, if you prefer)<br>
>     must follow a very different process (and technology) for submitting,<br>
>     reviewing, discussing, testing and landing patches, than  the rest of<br>
>     the toolkit?<br>
><br>
><br>
> There is probably no significant reason for promises to live in SDK code<br>
> except that that is where it started life. However I disagree that<br>
> submitting changes to SDK code will involve a different process for<br>
> submitting, reviewing, discussing or testing patches. All these steps<br>
> can be performed in bugzilla just as you do for trunk patches though and<br>
> if you don't feel up to landing the final change in github then we have<br>
> many engineers who would be happy to do it for you.<br>
<br>
</div>Well, the process described to me by SDK developers sounded anything but<br>
simple. It is possible, however, that I may have misunderstood it.<br>
Can you describe the process you propose for m-c developers who find<br>
themselves having to patch promises for some reason?<br></blockquote><div><br></div><div>The process we normally use to submit patches to the SDK within the team and from outside contributors is generally with github and pull requests but I'm going to assert that if we want our libraries to be used and contributed to by the rest of Mozilla then we shouldn't force every Mozilla developer to follow that process. The process I foresee you following would be to write a patch against m-c, submit it to bugzilla, request review, address review concerns and get the patch ready to land. This should match the process you follow for submitting patches for the rest of m-c. Ideally we then we land it in github and wait for a regular uplift from there to m-c but in some cases it is going to be acceptable to land in m-c as well as github.<br>
<br></div><div>I'm going to bring this up in a coming SDK meeting and make sure the whole team is on the same page with this.<br></div><div><br></div></div></div></div>