Ok. Enough bikeshedding - PR here: https://github.com/apache/airflow/pull/65629 Once it's approved and merged - I will ping contributors/new contributors etc.
J. On Tue, Apr 21, 2026 at 11:07 PM Ferruzzi, Dennis <[email protected]> wrote: > I was on the Board of Directors for our local makerspace for a few > years.... I have some idea 😋 > ________________________________ > From: Jarek Potiuk <[email protected]> > Sent: Tuesday, April 21, 2026 12:32 PM > 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. > > > > 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] > > > > >
