FYI...
check out https://issues.apache.org/jira/browse/INFRA-16602 where a lot of
this conversation is taking place.
On Wed, Aug 1, 2018 at 7:16 AM Taylor Edmiston wrote:
> To Fokko's point:
>
> > 2. We need to make sure that we close the Jira ourself.
>
> Do we have a preference between the iss
To Fokko's point:
> 2. We need to make sure that we close the Jira ourself.
Do we have a preference between the issue being closed by the PR sender vs
the PR merger? I had one merged today but didn't want to disrupt the
process if someone is already working on getting Jira issue closing
automate
Thanks for addressing this quickly Ash!
On Wed, Aug 1, 2018 at 11:06 AM Ash Berlin-Taylor <
ash_airflowl...@firemirror.com> wrote:
>
> > On 1 Aug 2018, at 09:43, Ash Berlin-Taylor <
> ash_airflowl...@firemirror.com> wrote:
> >
> > Hi Sergi,
> >
> > Yes, I agree, and I've asked (as a short term me
> On 1 Aug 2018, at 09:43, Ash Berlin-Taylor
> wrote:
>
> Hi Sergi,
>
> Yes, I agree, and I've asked (as a short term measure) for the comments to
> list and comments on every PR duplicating to Jira to be removed (so that the
> volume was as it was) -- we can then think about what we want t
Hi Sergi,
Yes, I agree, and I've asked (as a short term measure) for the comments to list
and comments on every PR duplicating to Jira to be removed (so that the volume
was as it was) -- we can then think about what we want to re-enable, perhaps to
a different list.
Fokko: the new Apache-hoste
I find the dev list has gotten extremely noisy with the move to Github.
Getting an email about every PR comment seems a bit excessive. Might it be
a good idea to not have this list subscribed to all the github updates?
People who are interested in such granular updates can still "watch" the
github
Hi Max,
We're totally on the same page, I think I've phrased it a bit clumsy.
Two things that I've noticed:
1. Apache is not being mirrored, is this expected behaviour?
MacBook-Pro-van-Fokko:incubator-airflow fokkodriesprong$ git reset --hard
apache/master
HEAD is now at dfa7b26d [AIRFLOW-2809
I've also updated https://issues.apache.org/jira/browse/INFRA-16602 with
some questions for pono!
-s
On Tue, Jul 31, 2018 at 5:56 PM Sid Anand wrote:
> I've opened the following ticket to disable the "Merge Commits" option in
> the Merge Button, leaving the other 2 options available (e.g. Squas
I've opened the following ticket to disable the "Merge Commits" option in
the Merge Button, leaving the other 2 options available (e.g. Squash and
Merge, Rebase and Merge).
https://issues.apache.org/jira/browse/INFRA-16852
-s
On Tue, Jul 31, 2018 at 4:51 PM Sid Anand wrote:
> If squash & merge
If squash & merge does a rebase under the hood, then I agree that is the
way to go.
-s
On Tue, Jul 31, 2018 at 4:50 PM Sid Anand wrote:
> So, in GitHub, we can disable certain options. So under settings -->
> options, there is a section called "Merge Button", with 3 options: "Allow
> merge comm
So, in GitHub, we can disable certain options. So under settings -->
options, there is a section called "Merge Button", with 3 options: "Allow
merge commits", "Allow squash merging", and "Allow rebase merging". You can
see this on your fork but not on the
https://github.com/apache/incubator-airflow
What I meant by changing history is mutating one or many SHAs in the
branch, an operation that would require force-pushing, which merging
doesn't do. Personally I prefer "Squash & Merge" as it makes for a
merge-commit free `git log` and having a linear branch history in master
that aligns with when
Hi Max,
You're right. I just started plowing though my mailbox and merged a commit
without squash and merge, but it changes history as you mention.
Nice thing of Github is if you change it, it remembers your preference
which is Squash and Merge :-)
Love the Gitbox so far, great work!
Cheers, Fok
"Squash & Merge" (the default) does the right thing (squashes the multiple
commit and replays the resulting commit on top of master), we should use
that most of the times. We'd only want to merge if we wanted to preserve
history from within the PR (multiple collaborators or multiple important
commi
The other benefit of using Option 3 over Option 1 is that you maintain the
history of who committed and who authored in one line in the Git log-- i.e.
"bob33 authored and ashb committed 3 hours ago" instead of just "ashb
committed" for a merge commit followed by the commit(s) from bob33.
On Tue, J
Ash,
This is pretty cool. I just merged one PR from GH directly.
Interestingly, I still used the `dev/airflow-pr work_local` to test out the
PR, but merging directly in the GitHub UI afterwards definitely avoided my
needing to do another `dev/airflow-pr merge` CLI command.
There are 3 options in
We should ask Apache infra to send the GH notifs to another mailing
list.
Over at jclouds, we created a "notifications@" list for this purpose
(well, actually we renamed "issues@" to "notifications@"), and send
messages there:
https://issues.apache.org/jira/browse/INFRA-7180
https://mail-arc
We should ask Apache infra to send the GH notifs to another mailing list.
Max
On Mon, Jul 30, 2018 at 11:35 AM Ash Berlin-Taylor <
ash_airflowl...@firemirror.com> wrote:
> It appears we also have comments on Github issues being auto-duplicated to
> the dev mailing list -- this will increase the
It appears we also have comments on Github issues being auto-duplicated to the
dev mailing list -- this will increase the email volume on that list.
Would we like to keep that feature or disable it?
-ash
> On 30 Jul 2018, at 20:24, Ash Berlin-Taylor
> wrote:
>
> Hi everyone, but especially c
Hi everyone, but especially committers: we have now moved to Github, and should
be able to commit directly there (and close issues too hopefully).
If you are a committer and haven't yet linked your Github account with ASF go
to https://gitbox.apache.org/setup/ and follow the instructions.
If th
20 matches
Mail list logo
