Would this change to EmrAddStepsOperator make sense? If so I can go ahead
and create a ticket and a PR
On Wed, Nov 13, 2019 at 8:11 PM Aviem Zur wrote:
> Sure.
>
> While most EMR clusters are ephemeral, some of our use cases required
> persistent EMR clusters since the apps they run are short an
Agree that Github issue are nicely integrated with the code, I don't
particularly mind which issue tracking system I use as long as it has good
integration.
The nice part about github issues that now with github actions we could
automate more and have full control over it. And a lot of this works
On a slightly irrelevant note, do we ever close tickets as non-reproducable
or will-not-fix?
Last time I was going through open tickets I found dozens that seemed
really old, really not-gonna-happen or already fixed.
What actions could we take to decrease this gap?
WDYT?
S.
On Mon, 18 Nov 2019 at
Great initiative, I am in Berlin and happy to help.
S.
On Mon, 18 Nov 2019 at 20:43, Aizhamal Nurmamat kyzy
wrote:
> Hi Jarek,
>
> It will be great to have Polidea's support as well. I think we need to
> submit the proposal before going on Thanksgiving break to set the
> desirable dates. That's
I can agree that GitHub issues may get spammy but I other projects deal
with it somehow. And as a user I like the simplicity of creating an issue.
As per Jira, I think a good part of it is the ability to link issues across
different ASF project (but I don't think it's a killer feature).
On Mon, No
I don’t like Jira particularly but I like GitHub issues even less. Both
don’t feel right. And yes GitHub issues get spammy very quickly. The hurdle
gets so low that it functions as an alternative to the mailing list, far,
and chat.
On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (a...@apache.o
Getting creds for Jira might be tricky, though Infra may have some way of
resolving issues when PR is merged (please don't Close, only ever Resolve as
closed issues can't have FixVersion changed)
This brings me on to another question: what do were actual use Jira for that
couldn't (or shouldn't
Hi Jarek,
It will be great to have Polidea's support as well. I think we need to
submit the proposal before going on Thanksgiving break to set the
desirable dates. That's is usually the hardest part. The rest of the
details, like sponsors, venues and volunteers can be updated later when we
have mo
Is there any possibility to use GitHub actions for that?
For example, the one that allows to "Automatically transition an issue to
done when a pull request whose name contains the issue key is merged"?
Here is Atlassian repo: https://github.com/atlassian/gajira
Bests,
Tomek
On Mon, Nov 18, 2019
I wrote that script. It’s cli only unfortunately.
On 18 November 2019 at 18:22:04, Dan Davydov (ddavy...@twitter.com.invalid)
wrote:
Wait this doesn't happen automatically!? I thought way-back-when someone
wrote a script to automatically close the JIRA tickets (maybe that script
is not run when
Wait this doesn't happen automatically!? I thought way-back-when someone
wrote a script to automatically close the JIRA tickets (maybe that script
is not run when changes are merged via the UI). My apologies, will close
JIRAs in the future, I don't think I've closed any JIRA tickets manually.
On S
My 2 cents on the long-term plan:
Once Airflow has Dag Isolation (i.e. DAG python dependencies are completely
decoupled from Airflow), we should pin the core Airflow deps, and package
operators separately with version ranges (for the reasons Ash mentioned
about libraries vs applications).
On Sat,
12 matches
Mail list logo
