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 Mon, 22 Oct 2012 16:26:57 GMT
Good point, Shaz.  I'll make sure to create Improvement items for anything that gets itself
into a pull request.

Cheers,
Kevin


-----Original Message-----
From: Shazron [mailto:shazron@gmail.com] 
Sent: Sunday, October 21, 2012 10:06 PM
To: callback-dev@incubator.apache.org
Subject: Re: Best practices for contributing near a release boundary

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