I am good with both approaches, if there is an agreement. At least, from my point of view, freezing `master` doesn't prevent me from reviewing code nor opening new PRs. For the PR that has +1 and ready to merge, we just tag it 'LGTM', commit it once the branch is open to commit. Just click the button.
Thanks, Haisheng On 2020/05/13 21:45:53, Stamatis Zampetakis <zabe...@gmail.com> wrote: > I admit that Julian's idea already crossed my mind in the past but > observing the activity of the project for some time I am not very convinced > that will help. > I am afraid that it may discourage those few reviewers that are doing well > their part and have other undesirable side-effects like slowing down the > release cycle, increase the number of PRs and the conflicts. > Yet we never tried this in the past so we can give it a try and see what > happens. > > A more conservative approach could be to agree not to release 1.24.0 unless > certain PRs (from 1.23.0 or before) get in. > > Best, > Stamatis > > On Wed, May 13, 2020 at 9:52 PM Rui Wang <amaliu...@apache.org> wrote: > > > Not saying my opinion of whether supporting this proposal or not, but just > > add something to the proposal itself: > > > > There is a need to have a person (likely the release manager :-)) to check > > "fix in 1.23" Jira list to identify which Jira has a promising PR, and then > > create a much smaller Jira list (by removing 1.23.0 from the fix version > > from those non-promising Jiras). So the re-open of the Calcite master > > branch will depend on cleaning up that Jira list, by either merging PRs and > > closing Jiras, or changing that "fix in 1.23" because maybe the PR owner is > > not active. > > > > Basically if Calcite community goes in the direction of closing the master > > branch, then there should be a reasonable criteria that when the master > > branch can be re-open, and a manager to enforce Calcite meets that > > criteria. > > > > > > -Rui > > > > On Wed, May 13, 2020 at 11:59 AM Julian Hyde <jh...@apache.org> wrote: > > > > > I suggest keeping master closed to get some resources on this > > > important issue. Yes, it is a form of blackmail. > > > > > > On Tue, May 12, 2020 at 8:26 PM Chunwei Lei <chunwei.l...@gmail.com> > > > wrote: > > > > > > > > There're some PRs which have been a long time. I suggest closing some > > of > > > > them if nobody are working on it. > > > > But I don't figure out why we should keep the master branch closed. To > > > > avoid conflict? > > > > > > > > > > > > Best, > > > > Chunwei > > > > > > > > > > > > On Wed, May 13, 2020 at 2:22 AM Julian Hyde <jh...@apache.org> wrote: > > > > > > > > > I noticed that yesterday Haisheng removed the ‘fix in 1.23’ labels > > from > > > > > several JIRA cases. I support this - we need to get a release out - > > > but I > > > > > don’t want to lose the fact that many of these cases had PRs and were > > > ready > > > > > to merge to master. > > > > > > > > > > We all know that we have a backlog of PRs. There are good > > contributions > > > > > that are not being merged to master because we have too few > > reviewers. > > > > > > > > > > I would like to propose a solution. After 1.23 is released, keep the > > > > > master branch closed until we have gone through the backlog of PRs. > > > (Not > > > > > all PRs, just those that were tagged ‘fix for 1.23’. And we don’t > > have > > > to > > > > > merge them all - we can reject them if not ready.) > > > > > > > > > > Committers who work on Calcite daily will have a strong incentive to > > > work > > > > > on other peoples’ PRs. > > > > > > > > > > If there are other suggestions for addressing this problem, I would > > > like > > > > > to hear them. > > > > > > > > > > Julian > > > > > > > > > > > > > > > >
