That is the contrib flow as Brian described. Generally I would say that is enough but sometimes pull requests do get overlooked even though there is an email that is reported in this list. Once the email is read, it could be overlooked since it usually is acted on later, maybe even weeks later depending.
It certainly is not required, but a good thing would be to post a JIRA issue as well since there is a category for "improvements". I would still tag the fix version to "2.2.0" so we can triage. Shaz On Sun, Oct 21, 2012 at 3:30 PM, Brian LeRoux <b...@brian.io> wrote: > 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 >>
