calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haisheng Yuan <hy...@apache.org>
Subject Re: [DISCUSS] Keep 'master' branch closed after 1.23 release until we address the PR backlog
Date Wed, 13 May 2020 23:23:39 GMT
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 <zabetak@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 <amaliujia@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 <jhyde@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.leii@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 <jhyde@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
> > > > >
> > > > >
> > >
> >
> 

Mime
View raw message