Quick additional info - if you have in your repo a 'tests` or 'airflow'
folder remaining in the root of the repo - because you had some extra files
in those (for example generated node_modules) - you should delete those
two directories. They are now unused and any files remaining there can and
*SH
Also one more important point - if we drop `pip` support - we will be able
to rely on `uv.lock` for constraint generation. Currently we have our own
mechanism of updating the constraint files, but if we go "full-in" with
`uv` - we should be able to use `uv.lock` for this purpose. It means that
we
Overall I agree that decisions should be made in the devlist.
One improvement that I'd like to suggest, though, is to have a dedicated
page on cwiki that summarizes all recent and upcoming decisions (votes +
lazy consensus) in a table, including links to their respective devlist
threads. We could h
Excellent, good work Vincent!
Thank you for taking care of this and sharing all the details here.
Vikram
On Fri, Mar 21, 2025 at 1:58 PM Buğra Öztürk
wrote:
> Great work Vincent! Thanks for the details!
>
> On Fri, Mar 21, 2025 at 2:49 PM Bishundeo, Rajeshwar
> wrote:
>
> > Awesome job Vince
I completely agree regarding transparency, having options expressed in
writing, and tracking decisions.
I also support the ASF philosophy that voting should only happen on the dev
list.
However, treating the dev list as the only acceptable mechanism for
discussion feels overly burdensome, in my h
> Quick question: We will still make the branches for constraints as we
used to, correct?
Quick answer: Correct.
Longer answer with more context and future vision.
The constraints mechanism is currently used for both:
1) development (effectively pinning the dependencies for most PRs and only
bu
+1 from me - uv is a great tool, improves developer experience, and it is
well-supported.
While acknowledging the licensing issues that you mentioned - if migration
from the current dual license ever happens, I assume that we'll be able to
find solutions for that.
On Fri, Mar 21, 2025 at 11:51 PM
+1, I fully agree with the mechanism - it is open, transparent, gives
everyone an opportunity to participate, and keeps track of how the
decisions are made.
On Sat, Mar 22, 2025 at 5:34 PM Shahar Epstein wrote:
> Overall I agree that decisions should be made in the devlist.
> One improvement tha
That is brilliant!
I am loving the new repo structure and am absolutely amazed at how few/none
teething issues
such a move has introduced! Well executed Jarek!
Thanks & Regards,
Amogh Desai
On Fri, Mar 21, 2025 at 11:35 PM Elad Kalif wrote:
> Amazing work!
>
> On Fri, Mar 21, 2025 at 7:50 PM
I am OK with this decision too.
I personally am finding `uv` to be nice and super user friendly. No need to
go through
the past list of commands to install some package, `uv sync` just
simplifies things amazingly.
It is always a good idea to have one "solid" way of doing things rather
than multip
Yes, I am Ok with it and it is easy to use.
Pavan.
On Sat, Mar 22, 2025 at 11:58 AM Amogh Desai
wrote:
> I am OK with this decision too.
>
> I personally am finding `uv` to be nice and super user friendly. No need to
> go through
> the past list of commands to install some package, `uv sync`
Good work Daniel!
Thanks & Regards,
Amogh Desai
On Thu, Mar 20, 2025 at 6:04 PM Jarek Potiuk wrote:
> Same :)
>
> On Thu, Mar 20, 2025 at 11:30 AM Wei Lee wrote:
>
> > Love this!
> >
> > Best,
> > Wei
> >
> > > On Mar 20, 2025, at 4:15 AM, Daniel Standish
> > wrote:
> > >
> > > In what may go
OK. Let me clarify then,
1) First of all - yes - i completely missed cadwyn and API versioning we
agreed to in the AIP. We had so many of those AIPs that I simply forgot
this tiny-little detail. Totally my fault and sorry for calling that one
out. Sorry Ash for that if you felt you've been called
13 matches
Mail list logo
