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]
