Re: Github pull requests

[J. D. Jordan]

I think it goes the other way around. When you push to ASF git with the right 
commit message then the integration from that side closes the pull request.

> On Aug 28, 2016, at 11:48 PM, Jonathan Ellis  wrote:
> 
> Don't we need something on the infra side to turn a merged pull request
> into a commit to the ASF repo?
> 
> On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall 
> wrote:
> 
>>> 
>>> 
>>> Infra is exploring options for giving PMCs greater control over GitHub
>>> config (including allowing GitHub to be the master with a golden copy
>>> held at the ASF) but that is a work in progress.
>> ^  Per Mark's comment, there is not anything we can really do past what
>> Jake F. described with Thrift. We dealt with this with Usergrid back in
>> incubation two years ago (Jake F. actually helped us get it all sorted at
>> the time) when we were using https://github.com/usergrid/usergrid as the
>> source:
>> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
>> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
>> 
>> Here is the Thrift guide again for reference:
>> https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-
>> via-github-pull-requests
>> 
>> JClouds also has a nice write up/how-to (we based Usergrid on this,
>> initially):
>> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
>> 
>> Maybe we just amend our 'how-to-commit' with similar details as the two
>> references above?
>> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
>> 
>> -Nate
>> 
>> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall 
>> wrote:
>> 
>>> 
 Nate, since you have experience with this from Usergrid, can you figure
 out
 what we need to do to make this happen and follow up with infra?
>>> 
>>> Yep - i'll look into this.
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced

Re: Github pull requests

[Sylvain Lebresne]

Sorry for being obtuse but what do we win exactly?

The way we're currently working is that a lot of ticket spans 2 or more
branches so that most people currently submit patches by attaching link to
the
relevant branches (one for each version we should commit to) as well as
links
to the CI results for those branches. Unless we make serious changes to how
we
do things (but I, for one, wouldn't mind clarifications on those changes),
this doesn't seem to reduce itself well to a single pull request.

On Mon, Aug 29, 2016 at 2:45 PM, J. D. Jordan 
wrote:

> I think it goes the other way around. When you push to ASF git with the
> right commit message then the integration from that side closes the pull
> request.
>
> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis  wrote:
> >
> > Don't we need something on the infra side to turn a merged pull request
> > into a commit to the ASF repo?
> >
> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall 
> > wrote:
> >
> >>>
> >>>
> >>> Infra is exploring options for giving PMCs greater control over GitHub
> >>> config (including allowing GitHub to be the master with a golden copy
> >>> held at the ASF) but that is a work in progress.
> >> ^  Per Mark's comment, there is not anything we can really do past what
> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
> >> incubation two years ago (Jake F. actually helped us get it all sorted
> at
> >> the time) when we were using https://github.com/usergrid/usergrid as
> the
> >> source:
> >> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> >> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
> >>
> >> Here is the Thrift guide again for reference:
> >> https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> >> via-github-pull-requests
> >>
> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
> >> initially):
> >> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
> >>
> >> Maybe we just amend our 'how-to-commit' with similar details as the two
> >> references above?
> >> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
> >>
> >> -Nate
> >>
> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall 
> >> wrote:
> >>
> >>>
>  Nate, since you have experience with this from Usergrid, can you
> figure
>  out
>  what we need to do to make this happen and follow up with infra?
> >>>
> >>> Yep - i'll look into this.
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>

Re: Github pull requests

[Edward Capriolo]

>> I think it goes the other way around. When you push to ASF git with the
right commit message then the integration from that side closes the pull
request.

Yes. This is how apache-gossip is setup. Someone makes a JIRA and they
include a link to there branch and tell me they are done. We review

git checkout apache master
git pull otherperson jira-123
git push origin master

Ticket on github is "magically" closed.

On Mon, Aug 29, 2016 at 8:45 AM, J. D. Jordan 
wrote:

> I think it goes the other way around. When you push to ASF git with the
> right commit message then the integration from that side closes the pull
> request.
>
> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis  wrote:
> >
> > Don't we need something on the infra side to turn a merged pull request
> > into a commit to the ASF repo?
> >
> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall 
> > wrote:
> >
> >>>
> >>>
> >>> Infra is exploring options for giving PMCs greater control over GitHub
> >>> config (including allowing GitHub to be the master with a golden copy
> >>> held at the ASF) but that is a work in progress.
> >> ^  Per Mark's comment, there is not anything we can really do past what
> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
> >> incubation two years ago (Jake F. actually helped us get it all sorted
> at
> >> the time) when we were using https://github.com/usergrid/usergrid as
> the
> >> source:
> >> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> >> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
> >>
> >> Here is the Thrift guide again for reference:
> >> https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> >> via-github-pull-requests
> >>
> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
> >> initially):
> >> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
> >>
> >> Maybe we just amend our 'how-to-commit' with similar details as the two
> >> references above?
> >> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
> >>
> >> -Nate
> >>
> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall 
> >> wrote:
> >>
> >>>
>  Nate, since you have experience with this from Usergrid, can you
> figure
>  out
>  what we need to do to make this happen and follow up with infra?
> >>>
> >>> Yep - i'll look into this.
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>

Re: Github pull requests

[Jeff Jirsa]

I guess someone would have to open 3 different PRs (say, 2.2, 3.0, trunk), and 
the committer would have 3 different commit messages to close each of them? 

Anyone have examples of projects with branching strategies similar to ours 
using github pull requests?

On 8/29/16, 6:26 AM, "Sylvain Lebresne"  wrote:

>Sorry for being obtuse but what do we win exactly?
>
>The way we're currently working is that a lot of ticket spans 2 or more
>branches so that most people currently submit patches by attaching link to
>the
>relevant branches (one for each version we should commit to) as well as
>links
>to the CI results for those branches. Unless we make serious changes to how
>we
>do things (but I, for one, wouldn't mind clarifications on those changes),
>this doesn't seem to reduce itself well to a single pull request.
>
>On Mon, Aug 29, 2016 at 2:45 PM, J. D. Jordan 
> >
>wrote:
>
>> I think it goes the other way around. When you push to ASF git with the
>> right commit message then the integration from that side closes the pull
>> request.
>>
>> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis  wrote:
>> >
>> > Don't we need something on the infra side to turn a merged pull request
>> > into a commit to the ASF repo?
>> >
>> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall 
>> > wrote:
>> >
>> >>>
>> >>>
>> >>> Infra is exploring options for giving PMCs greater control over GitHub
>> >>> config (including allowing GitHub to be the master with a golden copy
>> >>> held at the ASF) but that is a work in progress.
>> >> ^  Per Mark's comment, there is not anything we can really do past what
>> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
>> >> incubation two years ago (Jake F. actually helped us get it all sorted
>> at
>> >> the time) when we were using 
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_usergrid_usergrid&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=QJDmpc1jGzcYxAuVgRITwhtE0pvI9cX89qzs4PYGOEw&e=
>> >>   as
>> the
>> >> source:
>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_usergrid-2Ddev_201405.mbox_-25&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=7kzsf7Cftf3JLs6mxfG9K977BOT4UsPhrNrF0AUNMxE&e=
>> >>  
>> >> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
>> >>
>> >> Here is the Thrift guide again for reference:
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_thrift_blob_master_&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=jWroE0rW19cTgXQevrVclo_vrOVZPm3ayttaIDlLsmY&e=
>> >>  
>> CONTRIBUTING.md#contributing-
>> >> via-github-pull-requests
>> >>
>> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
>> >> initially):
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_JCLOUDS_Git-2Bworkflow&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=myPol_9DxHRsfH9Qu4wumwGS85iQMim1H6adNG5q0Nw&e=
>> >>  
>> >>
>> >> Maybe we just amend our 'how-to-commit' with similar details as the two
>> >> references above?
>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cassandra.apache.org_doc_latest_development_how-5Fto-5Fcommit.html&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=4uaZpa4HwH5Zmy1kcnup2pF7IVDFSNugBV7oKrDNFqA&e=
>> >>  
>> >>
>> >> -Nate
>> >>
>> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall 
>> >> wrote:
>> >>
>> >>>
>>  Nate, since you have experience with this from Usergrid, can you
>> figure
>>  out
>>  what we need to do to make this happen and follow up with infra?
>> >>>
>> >>> Yep - i'll look into this.
>> >
>> >
>> >
>> > --
>> > Jonathan Ellis
>> > Project Chair, Apache Cassandra
>> > co-founder, 
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.datastax.com&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=X4Ry4_CijxQv9T0pV128swtLPYwyImU73IBOUAzfGig&e=
>> >  
>> > @spyced
>>


smime.p7s
Description: S/MIME cryptographic signature

Proposal: create a mailing list for just the newly created Jira ticket notifications

[Jeremy Hanna]

Currently we have a mailing list (commits@) that includes commit messages as 
well as all updates to Jira tickets.  However for the purpose of staying up to 
date with new tickets, it’s something of a firehose with the rapid rate of 
change.

Some people (like me) filter out just the new ticket creation emails and 
watch/vote for those that seem interesting.  Others create Jira filters and 
subscribe to them.  Personally I prefer an email per Jira creation.  For those 
that prefer that route, would anyone mind if I created an infra ticket to 
create a mailing list to just publish those emails?  Are there others like me 
out there that prefer that to doing a daily digest or something similar?

Thanks,

Jeremy

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

[Jonathan Haddad]

A daily digest of new issues would be incredible.  A non-binding +1 from
this guy.


On Mon, Aug 29, 2016 at 8:58 AM Jeremy Hanna 
wrote:

> Currently we have a mailing list (commits@) that includes commit messages
> as well as all updates to Jira tickets.  However for the purpose of staying
> up to date with new tickets, it’s something of a firehose with the rapid
> rate of change.
>
> Some people (like me) filter out just the new ticket creation emails and
> watch/vote for those that seem interesting.  Others create Jira filters and
> subscribe to them.  Personally I prefer an email per Jira creation.  For
> those that prefer that route, would anyone mind if I created an infra
> ticket to create a mailing list to just publish those emails?  Are there
> others like me out there that prefer that to doing a daily digest or
> something similar?
>
> Thanks,
>
> Jeremy

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

[Russell Hatch]

This is currently possible using jira saved search + subscription. Create a
new saved search with a query like:

project = CASSANDRA AND created >= -24h ORDER BY createdDate DESC

When viewing your filter, go to Details > New Subscription and set it up to
run once a day and you're set!

Hope it helps,

Russ

On Mon, Aug 29, 2016 at 10:45 AM, Jonathan Haddad  wrote:

> A daily digest of new issues would be incredible.  A non-binding +1 from
> this guy.
>
>
> On Mon, Aug 29, 2016 at 8:58 AM Jeremy Hanna 
> wrote:
>
> > Currently we have a mailing list (commits@) that includes commit
> messages
> > as well as all updates to Jira tickets.  However for the purpose of
> staying
> > up to date with new tickets, it’s something of a firehose with the rapid
> > rate of change.
> >
> > Some people (like me) filter out just the new ticket creation emails and
> > watch/vote for those that seem interesting.  Others create Jira filters
> and
> > subscribe to them.  Personally I prefer an email per Jira creation.  For
> > those that prefer that route, would anyone mind if I created an infra
> > ticket to create a mailing list to just publish those emails?  Are there
> > others like me out there that prefer that to doing a daily digest or
> > something similar?
> >
> > Thanks,
> >
> > Jeremy
>

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

[Jonathan Haddad]

Wow, I am embarrassed to say that I had no idea that existed.  Thanks Russ!

On Mon, Aug 29, 2016 at 9:58 AM Russell Hatch  wrote:

> This is currently possible using jira saved search + subscription. Create a
> new saved search with a query like:
>
> project = CASSANDRA AND created >= -24h ORDER BY createdDate DESC
>
> When viewing your filter, go to Details > New Subscription and set it up to
> run once a day and you're set!
>
> Hope it helps,
>
> Russ
>
> On Mon, Aug 29, 2016 at 10:45 AM, Jonathan Haddad 
> wrote:
>
> > A daily digest of new issues would be incredible.  A non-binding +1 from
> > this guy.
> >
> >
> > On Mon, Aug 29, 2016 at 8:58 AM Jeremy Hanna  >
> > wrote:
> >
> > > Currently we have a mailing list (commits@) that includes commit
> > messages
> > > as well as all updates to Jira tickets.  However for the purpose of
> > staying
> > > up to date with new tickets, it’s something of a firehose with the
> rapid
> > > rate of change.
> > >
> > > Some people (like me) filter out just the new ticket creation emails
> and
> > > watch/vote for those that seem interesting.  Others create Jira filters
> > and
> > > subscribe to them.  Personally I prefer an email per Jira creation.
> For
> > > those that prefer that route, would anyone mind if I created an infra
> > > ticket to create a mailing list to just publish those emails?  Are
> there
> > > others like me out there that prefer that to doing a daily digest or
> > > something similar?
> > >
> > > Thanks,
> > >
> > > Jeremy
> >
>

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

[Patrick McFadin]

I have one setup for new AND updated. Very handy to seeing activity
progression.

Jira has some really nice query + notification settings if you want to get
more granular.

On Mon, Aug 29, 2016 at 10:12 AM, Jonathan Haddad  wrote:

> Wow, I am embarrassed to say that I had no idea that existed.  Thanks Russ!
>
> On Mon, Aug 29, 2016 at 9:58 AM Russell Hatch  wrote:
>
> > This is currently possible using jira saved search + subscription.
> Create a
> > new saved search with a query like:
> >
> > project = CASSANDRA AND created >= -24h ORDER BY createdDate DESC
> >
> > When viewing your filter, go to Details > New Subscription and set it up
> to
> > run once a day and you're set!
> >
> > Hope it helps,
> >
> > Russ
> >
> > On Mon, Aug 29, 2016 at 10:45 AM, Jonathan Haddad 
> > wrote:
> >
> > > A daily digest of new issues would be incredible.  A non-binding +1
> from
> > > this guy.
> > >
> > >
> > > On Mon, Aug 29, 2016 at 8:58 AM Jeremy Hanna <
> jeremy.hanna1...@gmail.com
> > >
> > > wrote:
> > >
> > > > Currently we have a mailing list (commits@) that includes commit
> > > messages
> > > > as well as all updates to Jira tickets.  However for the purpose of
> > > staying
> > > > up to date with new tickets, it’s something of a firehose with the
> > rapid
> > > > rate of change.
> > > >
> > > > Some people (like me) filter out just the new ticket creation emails
> > and
> > > > watch/vote for those that seem interesting.  Others create Jira
> filters
> > > and
> > > > subscribe to them.  Personally I prefer an email per Jira creation.
> > For
> > > > those that prefer that route, would anyone mind if I created an infra
> > > > ticket to create a mailing list to just publish those emails?  Are
> > there
> > > > others like me out there that prefer that to doing a daily digest or
> > > > something similar?
> > > >
> > > > Thanks,
> > > >
> > > > Jeremy
> > >
> >
>

Failing tests 2016-08-29

[Joel Knighton]

3.9 hasn't had any new runs. Today's results are for trunk.

===
testall: All passed!

===
dtest: Only one meta-test failure. This has been resolved.

===
novnode: Same as dtests above.

===
upgrade: 1 failure
  upgrade_tests.cql_tests
  .TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x
  .bug_5732_test
  CASSANDRA-12457. This issue is still in progress.

>From looking at 3.0.x and trunk more lately, it looks like the test fixing
efforts toward 3.9 have had a positive effect across all branches.