I am fully OK with Jareks proposals. Use it the same. (But would be okay
with "apache" as well but the rationale with Agent is a good point!)
On 21.04.26 21:32, Jarek Potiuk wrote:
You are not on ASF mailing lists - you know nothing about bike-shedding :)
On Tue, Apr 21, 2026 at 9:09 PM Ferruzzi, Dennis <[email protected]>
wrote:
In the end, we're all free do use whichever we prefer for our own
environments and we are bikeshedding a doc change. I appreciate whichever
you decide to standardize the docs on, Jarek.
________________________________
From: Vincent Beck <[email protected]>
Sent: Tuesday, April 21, 2026 7:31 AM
To: [email protected] <[email protected]>
Subject: RE: [EXT] [DISCUSS] standardizing fork names for Airflow remjotes
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know
the content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe.
Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez
pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que
le contenu ne présente aucun risque.
Makes sense to me to use upstream and origin
On 2026/04/21 12:19:55 Jarek Potiuk wrote:
Good feedback :) I am glad to see it coming :).
Just to be sure, standardizing isn't a "must"; for me it's really more of
avoiding ambiguities in the docs, and making manual and agentic
contributions. I am on a quest to cut every unnecessary corner of our
process to minimize time loss for individuals.
We already had two iterations in our docs to guide agents on which
remotes
to push to (mine [1] and Kaxil's [2]). Both guides would be basically
unnecessary, and I saw my agent struggling quite a bit and losing tokens
while figuring out what to do, so I thought it might be good if we
standardize. We also use different conventions in different parts of the
docs, so it an also confuse people.
I personally used "apache" and "origin" so far, but I recently switched
to
"upstream"/"origin," which made my agent's work and manual pushes
significantly easier (And I switched almost instantly).
My proposal is to switch to "upstream" and "origin".
For those using agents, we can add instructions for them to clean up the
setup if they see we do not follow the convention. The agent will then
propose a one-time migration to the new standard.
J.
[1] https://github.com/apache/airflow/pull/62575
[2] https://github.com/apache/airflow/pull/62748
J.
On Tue, Apr 21, 2026 at 11:12 AM Piyush Mudgal <
[email protected]>
wrote:
I use upstream for apache/airflow and origin for personal forks as
it's a
pretty common github convention
Best,
Piyush
On Tue, Apr 21, 2026 at 12:53 PM Wei Lee <[email protected]> wrote:
I'm also using "apache" for "apache/airflow". (but I use "upstream"
for
all
other projects...) Either way kinda works for me. like "apache" a bit
more,
but I'm ok with "upstream".
Best,
Wei
Shahar Epstein <[email protected]> 於 2026年4月21日週二 下午2:52寫道：
Personally I'm used to "apache" as the upstream name, but I could
live
with
"upstream".
Shahar
On Tue, Apr 21, 2026 at 2:24 AM Jarek Potiuk <[email protected]>
wrote:
Hello,
While preparing release documentation, I noticed that we use
quite
different approaches for remote naming in various examples and
tutorials.
Standardizing on those remotes would be easier for both new
contributors
and agents; currently, we have some instruction on how to find
the
righ
remotes.
I would like to propose very simple approach:
* *upstream* -> apache/airflow
* *origin* -> your fork
We could add instructions for checking out and adding airflow to
follow
the
convention. This would also make our documentation more
consistent
and
agent-followable, reducing back-and-forth.
And renaming remotes is easy - so would be quite easy for people
to
switch
(other than muscle memory).
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
