Sounds good, Although I'm also fine with doing votes on design docs prior to PR's if that makes more sense. But generally having some gateway of "these changes are going to be implemented"
On Fri, Mar 14, 2025 at 3:11 AM Robert Stupp <sn...@snazy.de> wrote: > +1 > > on Dmitri's proposal > > On 14.03.25 07:52, Jean-Baptiste Onofré wrote: > > Hi Dmitri > > > > Thanks for starting this discussion. > > > > I thought we already agreed on that. If we take a look on > > https://polaris.apache.org/community/contributing-guidelines/ we can > > see in the good practices section (first bullet point): > > > > "Change of public interface (or more generally speaking Polaris > > extension point) should be discussed and approved on the dev mailing > > list. The discussion on the dev mailing list should happen before > > having a “ready-for-review” Pull Request." > > > > My view on it also covers REST API changes, as client-facing APIs. > > > > So, I agree with your proposal, I thought it was clearly stated to the > > community, but it seems not :) > > > > Regards > > JB > > > > On Fri, Mar 14, 2025 at 1:56 AM Dmitri Bourlatchkov <di...@apache.org> > wrote: > >> Hi All, > >> > >> A lot of REST API changes have been happening lately in GitHub. > >> > >> Client-facing APIs changes are relatively a lot more important than > >> refactorings and other code fixes, but can easily be hidden from view in > >> the multitude of GH notifications. > >> > >> Therefore, I propose to run votes on the dev list for REST API changes > >> after the initial review on the PR. > >> > >> WDYT? > >> > >> Thanks, > >> Dmitri. > > -- > Robert Stupp > @snazy > >
