ve made the word easier to spell".
> >
> > J.
> >
> >
> >
> >>
> >>
> >> You can see the git commit messages is MUCH longer than the code change
> >> itself even! So if you're curious why that code is the way it is, you
> can
>
're curious why that code is the way it is, you can
>> just git blame it and have all the context there.
>>
>> The ADR having markdown is nice, it allows you a bit more formatting, but
>> then it also requires a couple more steps to view that formatting.
&
a couple more steps to view that formatting.
>
> Cheers,
> Niko
>
>
> From: Vincent Beck
> Sent: Monday, December 4, 2023 11:22:54 AM
> To: dev@airflow.apache.org
> Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Capturing
> Architectura
] [DISCUSS] Capturing Architectural
decisions (ADRS?)
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
I love this idea. I definitely think it can improve a lot the knowledge sharing
across Airflow. Given the history and the number of components in Airflow, it
is hard to keep up with everything, so having these ADRs would help a lot I
think!
On 2023/12/03 23:57:11 Jarek Potiuk wrote:
> Hey
I am in support of having adrs, and perhaps it's be helpful if there can be
a brief description on what kind of changes would need an adr. Also if we
can have a reminder on precommit which tells a committer to add an adr if a
change fits some criteria (lines of code change or any other kind of
I've successfully adopted this technique in the past and it served well
for some use-cases. What I loved about ADR was its simplicity and
transparency.
As you mentioned - it's not a "one solution fits all" kind of thing. I'd
love to have a summary for a given decision captured with ADR rather
Hey everyone,
I think we had a bit of clash in
https://github.com/apache/airflow/pull/32319 where both "ideas"
(serialization and common.sql) had not been sufficiently
discussed/explained and I hope we can address it by adding (a bit) more
"whys" to our (developer) documentation.
I think a
