Oh sorry that was gone with flame (please just consider it as my fault) and I just removed all comments.
Btw, when I always initiate discussions, I really do love to start discussion "without" specific instances which tend to go blaming each other. I understand it's not easy to discuss without taking examples, but I'll try to explain the situation on my best instead. Please let me know if there's some ambiguous or unclear thing to think about. On Sat, Nov 14, 2020 at 3:41 PM Sean Owen <sro...@gmail.com> wrote: > 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) >> >
