incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Making changes to callback API
Date Thu, 01 Dec 2011 21:15:58 GMT
Agree this sort of thing belongs in the JS --- sub component makes
sense since its a new proj that stands alone anyhow. I think, and
mentors pls correct me here, that the first step is a general
[DISCUSS] thread, followed or accompanied by a [POLL] to help
determine options, followed by a [VOTE] if rough consensus isn't good
enough.

>From there, add an issue to JIRA and get hacking. Once its done, well,
we have a process there currently that is informal w/ pull requests on
Github but I suspect we may want to formalize it a bit more w/ an
email identifying the patch/pull req on github for others to verify
before the final merge.


On Thu, Dec 1, 2011 at 12:28 PM, Filip Maj <fil@adobe.com> wrote:
> What do we do when we have platform-agnostic changes to introduce? Or want to suggest
a change for the API in general? For example, adding a new option to some callback API, like
allowing arbitrary headers to be set on a FileTransfer object.
>
> Does it make sense to add a new component to JIRA, like a JS component? There would be
a tight mapping from JS/API tickets to the callback-js project. Another related question is,
where is the starting point for development for these kinds of issues? My intuition is the
callback-js project and the docs…
>
> Obviously the first step is to vet the changes out on the mailing list so everyone can
chime in. But say we agree on a change – what's the next step after that?

Mime
View raw message