incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
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

>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 <> 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?

View raw message