+1 from me. `upstream` for `apache/airflow` and `origin` for personal forks seems like a sensible convention, and it aligns with what many large open source projects already use.
Best, Aaron On Mon, Apr 20, 2026 at 8:46 PM Pratiksha Badheka < [email protected]> wrote: > Nice point on maintaining consistency! > > I also use "upstream" but it is possible that some contributors may already > have upstream pointing to a different repository in that case we might need > to add more context to avoid any confusion . > Looking forward to hearing from the community ! > > Thanks & Regards, > Pratiksha badheka > > > On Tue, Apr 21, 2026 at 8:26 AM Aritra Basu <[email protected]> > wrote: > > > I'm good with upstream and origin, that's what I already use. Though I > > don't know if that additional info adds value in the docs. > > > > -- > > Regards, > > Aritra Basu > > > > On Tue, 21 Apr 2026, 5:19 am Jarek Potiuk, <[email protected]> wrote: > > > > > > I'm fine with whatever, and not trying to bikeshed, but why not use > > > `airflow` and `origin`? > > > > > > Because both are technically airflow :) . Upstream is pretty > unambiguous. > > > > > > On Tue, Apr 21, 2026 at 1:31 AM Ferruzzi, Dennis <[email protected]> > > > wrote: > > > > > > > I'm fine with whatever, and not trying to bikeshed, but why not use > > > > `airflow` and `origin`? > > > > ________________________________ > > > > From: Jarek Potiuk <[email protected]> > > > > Sent: Monday, April 20, 2026 4:24 PM > > > > To: [email protected] <[email protected]> > > > > Subject: [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. > > > > > > > > > > > > > > > > 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? > > > > > > > > > >
