cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: Best practices for contributing near a release boundary
Date Mon, 22 Oct 2012 05:06:05 GMT
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.


On Sun, Oct 21, 2012 at 3:30 PM, Brian LeRoux <> 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]
> On Sun, Oct 21, 2012 at 3:07 PM, Kevin Hawkins <> 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
>> 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

View raw message