calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert <zinki...@gmail.com>
Subject Re: [DISCUSS] Committer duties
Date Wed, 28 Mar 2018 08:41:05 GMT
I saw FLINK has a weekly update, this might be a useful way to let people
know more about what's happening.

On Wed, Mar 28, 2018 at 10:10 AM, Michael Mior <mmior@uwaterloo.ca> wrote:

> I wasn't suggesting that people submitting issues or PRs do the assigning.
> Aside from time, my biggest challenge to contributing more is not knowing
> who to ping since my own expertise is fairly limited. My thinking behind
> owners is just that it would make it clear who has the expertise in certain
> areas. But since the consensus seems to be against it, I'm fine with going
> with any alternative that works.
>
> --
> Michael Mior
> mmior@apache.org
>
> 2018-03-27 21:41 GMT-04:00 Julian Hyde <jhyde@apache.org>:
>
> > I agree with Jesus. I think it’s more important to deal with the
> > management, and have a person to handle incoming PRs, than to try to
> break
> > the product into well-defined components.
> >
> > "Component owners” are problematic because it’s not always clear
> > (especially to contributors) which parts of the code a given PR touches.
> A
> > vertical feature such as CREATE TYPE (CALCITE-2045) or authorization
> > (CALCITE-2194) will often cut through everything.
> >
> > In contrast, a coordinator would just assign PRs to people with the
> > necessary expertise, not do the reviewing. The load on them would be
> light
> > enough that they might volunteer to do it in some future month, which is
> > good, because we don’t want to burn anyone out.
> >
> > Julian
> >
> >
> > > On Mar 27, 2018, at 4:38 PM, Jesus Camacho Rodriguez <
> > jcamacho@apache.org> wrote:
> > >
> > > IMO the most important task is to stay on top of the issues and PRs,
> > > 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.
> > >
> > > -Jesús
> > >
> > >
> > >
> > > On 3/27/18, 2:33 PM, "F21" <f21.groups@gmail.com> 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.
> > >
> > >    Francis
> > >
> > >    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 <mmior@uwaterloo.ca>
> > 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
> > >>> mmior@apache.org
> > >>>
> > >>> 2018-03-27 12:40 GMT-04:00 Julian Hyde <jhyde@apache.org>:
> > >>>
> > >>>> 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
> > only
> > >>> 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
> > >>>>
> > >>>>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>



-- 
~~~~~~~~~~~~~~~
no mistakes
~~~~~~~~~~~~~~~~~~

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