Thanks Brian. Yeah, I would generally follow the workflow proposed in the ContributorWorkflow link; I just wasn't sure if that would present any specific issues near the release boundary. I suppose pull requests can simmer for a while anyway, as opposed to having to pull them in immediately upon submission.
I'll send a separate follow-up email with the proposed changes. They're relatively minor. Unrelated question: Is it normal that I don't get copied on posts I make to the email list, or am I inadvertently filtering those away locally, somehow? Cheers, Kevin -----Original Message----- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Sunday, October 21, 2012 3:31 PM To: callback-dev@incubator.apache.org Subject: Re: Best practices for contributing near a release boundary Create a topic branch with only the proposed changes. Ideally, a collection of small commits. Send pull request to our Github mirror to notify us (or send an email to the list). Likely Shaz, but really any another committer focusing on iOS can review, and merge. (Making sure you've signed the CLA, etc.) More info on our wiki here. [1] Might be a good idea to open discussion of the nature of the improvements. Could be we do want to land them before 2.2! [1] http://wiki.apache.org/cordova/ContributorWorkflow On Sun, Oct 21, 2012 at 3:07 PM, Kevin Hawkins <khawk...@salesforce.com> wrote: > Hi all, > > I've got a couple of "Improvements" I'd like to contribute to the iOS side of > the Cordova project. However, I know we're super close to the 2.2 release > boundary, and I don't feel strongly that these changes would need to be in > 2.2-actually, I feel strongly that, process-wise, this is *not* the time to > commit feature updates in a release cycle, at least to the imminent release. > > So what's the best course of action here? Would it be better to attach git > patches to the Improvement items I create? Or some other approach? > > Thanks, > Kevin >
