Failing tests 2016-08-29

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

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

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

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

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

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

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

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

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

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

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

Re: Github pull requests

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

Re: Github pull requests

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

Re: Github pull requests

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

Re: Github pull requests

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