Hi Alina, I don't speak for the whole community but one approach I took in the past [1] was opening a huge PR that does "everything" and as the reviews on that one progressed I would extract smaller, self-contained PRs that got more detailed reviews. Once those were merged, I would rebase and repeat the process until the big PR was simple enough and ready for merge.
The big PR allowed things to be seen by the reviewers in context and when they requested complicated changes or changes in infrastructure I would do those in separate PRs. For me, as the author, I've got the feeling I was making steady progress. [1] https://github.com/apache/arrow/pull/35345 -- Felipe On Tue, Apr 1, 2025 at 2:59 PM Alina Li <alina...@improving.com.invalid> wrote: > Greetings community, > > This email is regarding GitHub issue#30622 [1] for the Arrow ODBC Driver. > My colleague Rob and I are planning to work on the ODBC API layer to for > flightsql-odbc backend. So we would like to know the community's preference > for PR formats. For starters, I am thinking that we could perhaps create > small PRs for each work piece, and create new GitHub issues to associate > with each PR and make the new issues reference GitHub issue#30622 [1] as > parent. Please let me know if this approach makes sense and your thoughts. > Thanks! cc @David Li > > [1]: https://github.com/apache/arrow/issues/30622 > > Cheers, > Alina > > >
