+1 non-binding
On 07/06/2015 01:47 PM, Jake Luciani wrote:
I propose the following artifacts for release as 2.2.0-rc2.
sha1: ebc50d783505854f04f183297ad3009b9095b07e
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-rc2-tentative
Artifacts:
https://reposit
+1 non-binding
On 07/06/2015 12:04 PM, Jake Luciani wrote:
I propose the following artifacts for release as 2.1.8.
sha1: db39257c34152f6ccf8d53784cea580dbfe1edad
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.8-tentative
Artifacts:
https://repository.apac
-1. I've found some problems with 2.2 commit log replay in
https://issues.apache.org/jira/browse/CASSANDRA-9749 that could lose data
in some situations.
On Wed, Jul 8, 2015 at 7:19 AM Michael Shuler
wrote:
> +1 non-binding
>
> On 07/06/2015 01:47 PM, Jake Luciani wrote:
> > I propose the follow
As some of you might have noticed, Tyler and I tossed around a couple of
thoughts yesterday regarding the best way to perform larger reviews on JIRA.
I've been leaning towards the approach Benedict's been taking lately
w/putting comments inline on a branch for the initial author to inspect as
that
Hi,
I really like github’s workflow. If you don’t abuse it you get a history of the
entire review process.
Right now some people have a workflow that involves force pushing and deleting
branches. If you delete branches I think the pull requests are still valid so
people can still do it (althou
I've started leaning towards a hybrid approach:
I put everything I want to say, including some code changes, and sometimes
complex argumentation into comments the branch. I differentiate these into
two categories:
1. Literal comments, to remain for posterity - typically things I agree
with,
putting comments inline on a branch for the initial author to inspect
I agree and I think we can support this by using github pull requests for
review.
Pull requests live forever even if the source branch is removed. See
https://github.com/apache/cassandra/pull/4
They also allow for comments to b
The ability to navigate a patch in an IDE and add comments while exploring
is not something the github PR interface can provide; I expect I at least
would end up having to use multiple tools to perform a review given the PR
approach.
On Wed, Jul 8, 2015 at 3:50 PM, Jake Luciani wrote:
> putting
Hi,
If you navigate in an IDE how do you know if you are commenting on code that
has changed or not?
My workflow is usually to look at the diff and have it open in an IDE
separately, but maybe I am failing hard at tools.
Ariel
> On Jul 8, 2015, at 4:00 PM, Josh McKenzie wrote:
>
> The abilit
Spark has been using the GitHub PRs successfully; they have an additional
mailing list which contains updates from GitHub (
http://mail-archives.apache.org/mod_mbox/spark-reviews/), and they also
have their PRs linked to JIRA so that going from the ticket to the PR is
easily done.
If we are going
>
> If you navigate in an IDE how do you know if you are commenting on code
> that has changed or not?
I end up in the diff view and alt-tabbing over to the code view to look for
details to navigate. In retrospect, working with a github diff would just
be tabbing between a browser and IDE vs. an I
Except that it would lack code navigation. So it would be alt-tabbing, then
clicking through the clunky interface to find the file I want, and the
location, which can be very cumbersome.
On Wed, Jul 8, 2015 at 9:13 PM, Josh McKenzie
wrote:
> >
> > If you navigate in an IDE how do you know if y
(git history navigation is also much more powerful in the IDE, in my
experience - can quickly scoot through many prior versions to see what the
context of prior authors was)
On Wed, Jul 8, 2015 at 9:15 PM, Benedict Elliott Smith <
belliottsm...@datastax.com> wrote:
> Except that it would lack cod
When we set up autojobs for the dev branches, I did some digging around
the jenkins / githubPR integration, similar to what spark is doing. I'd
be completely on board with working through that setup, if it helps this
workflow.
Michael
On 07/08/2015 03:02 PM, Carl Yeksigian wrote:
Spark has b
14 matches
Mail list logo