calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "苑海胜" <>
Subject Re: Re: [DISCUSS] Committer duties
Date Wed, 28 Mar 2018 01:41:22 GMT
Agree with Jesus that what we need is not component owners, but comitters who can actively
involve in issue discussion and patch review.
Thanks ~Haisheng Yuan
------------------------------------------------------------------发件人:Jesus Camacho
Rodriguez<>日 期:2018年03月28日 07:38:23收件人<>主 题:Re:
[DISCUSS] Committer dutiesIMO the most important task is to stay on top of the issues and
I am not so concerned about the other project management tasks
since it is easier to do them collaboratively.

I think we do not need owners for components, as it will not help the
project in any way. If an owner does not review some PRs, what are
we going to do? Effectively, we cannot force him/her to do it timely,
and at the same time, we do not want to hold commits to the project
till the owner decides to review the PR.

Committers are more familiar with each other's work so we (the
committers) could try to proactively monitor the mailing list for
new issues and help contributors by reviewing or pinging the right
reviewer for each of them. Ultimately, it is our responsibility
as a community to commit those patches and keep the project
moving forward. This means that we may need to step up and
review a certain patch as well as we can, even if we are less
familiar with a certain module.


On 3/27/18, 2:33 PM, "F21" <> wrote:

    Hey everyone,
    I am happy to take ownership of the Go avatica client. I am currently 
    quite busy, but I hope to test it against the latest version of avatica 
    released a couple of weeks ago and see if we can make a release for it.
    On 28/03/2018 6:27 AM, Shuyi Chen wrote:
    > Hi Julian and Michael,
    > Thanks a lot for starting the discussion. I think the ownership model is a
    > good idea, and has been used by other open source communities, and we can
    > further break down core into e.g. sql parser, sql validator, relational
    > algebra, planner, JSON model, runtime and etc,.  Also, we need to add the
    > 'server' module into the JIRA component list for DDLs. And I think adding
    > component in the PR title will help owner to filter and identify issues
    > quickly, also I think we can use a template to enforce a more detail PR
    > description, so the reviewer can better understand the context and review
    > the code.
    > I have some knowledge in sql parser, JSON model, relational algebra and
    > planner, and is currently working on the server module to add the
    > type/library/function DDLs. I can definitely help on answering questions on
    > mailing list, reviewing code and contributing PRs for these components.
    > Also, I am definitely interested in learning and helping more on committing
    > code and doing releases as well.
    > Cheers
    > Shuyi
    > On Tue, Mar 27, 2018 at 9:51 AM, Michael Mior <> wrote:
    >> Thanks for starting the discussion Julian. I suggested at some point in the
    >> past that we figure out people who are willing to take ownership over
    >> certain components of Calcite. It seems like this would at least be a start
    >> to staying on top of PRs and issues. However, we would probably have to
    >> segment core practically for this to help.
    >> Another thing that comes to mind is staying on top of updates to
    >> dependencies. If people are owning certain components, hopefully they would
    >> also be willing to do a quick check around release time to see if new
    >> versions of dependencies for that component have been released and test and
    >> update if possible.
    >> Then there's also more administrative tasks such as making releases and
    >> ensuring a good flow of new committers and PMC members. Anything else I'm
    >> missing?
    >> Cheers,
    >> --
    >> Michael Mior
    >> 2018-03-27 12:40 GMT-04:00 Julian Hyde <>:
    >>> I’m not working full-time on Calcite anymore. But this project still
    >> needs
    >>> regular — daily — work to stay on top of contributions. If there’s
    >> one
    >>> person doing the work then one will is likely to become zero.
    >>> Let’s come up with a plan — with some commitments — for how this work
    >> will
    >>> get done.
    >>> Julian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message