I am sure you are referring to some specific instances but I have not followed enough to know what they are. Can you point them out? I think that is most productive for everyone to understand.
On Fri, Nov 13, 2020 at 10:16 PM Jungtaek Lim <kabhwan.opensou...@gmail.com> wrote: > Hi devs, > > I know this is a super sensitive topic and at a risk of flame, but just > like to try this. My apologies first. > Assuming we all know about the ASF policy about code commit and I don't > see Spark project has any explicit BYLAWS, it's technically possible to do > anything for committers to do during merging. > > Sometimes this goes a bit depressing for reviewers, regardless of the > intention, when merger makes a judgement by oneself to merge while the > reviewers are still in the review phase. I observed the practice is used > frequently, under the fact that we have post-review to address further > comments later. > > I know about the concern that it's sometimes blocking unintentionally if > we require merger to gather consensus about the merge from reviewers, but > we also have some other practice holding on merging for a couple of days > and noticing to reviewers whether they have further comments or not, which > is I think a good trade-off. > > Exclude the cases where we're in release blocker mode, wouldn't we be hurt > too much if we ask merger to respect the practice on noticing to reviewers > that merging will be happen soon and waiting a day or so? I feel the > post-review is opening the possibility for reviewers late on the party to > review later, but it's over-used if it is leveraged as a judgement that > merger can merge at any time and reviewers can still continue reviewing. > Reviewers would feel broken flow - that is not the same experience with > having more time to finalize reviewing before merging. > > Again I know it's super hard to reconsider the ongoing practice while the > project has gone for the long way (10 years), but just wanted to hear the > voices about this. > > Thanks, > Jungtaek Lim (HeartSaVioR) >