incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Hawkins <khawk...@salesforce.com>
Subject RE: Best practices for contributing near a release boundary
Date Sun, 21 Oct 2012 22:53:21 GMT
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.leroux@gmail.com [mailto:brian.leroux@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 <khawkins@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
>

Mime
View raw message