Hey,
I think the main problem is still the lack of active committers/reviewers
and not so much the assignment.
Totally agree - I think this is the core of the problem; the assign-by-files
could somewhat help pulling in the right people - but will not make the job
done.
We could opt for assigning PRs automatically using filename patterns. This
can be done rather easily and it's already done in various projects e.g.,
Hive [1].
I pioneered to make that happen - but I think it didn't really lifted off; for something like this to work; people should sign on volunteeringly (in which I think Calcite
is stronger).
I would definetly sign on to review some parts - but now I know: that even with
these requests there is no guarantee that I'll take a look...
One aspect of implementing this was to provide a way to keep an eye on key points of the project (in case of Hive: thrift api; metastore schema) to avoid possible issues
arising from conceptional problems.
Julian> Suppose that six committers volunteer to review and merge up to six PRs
per quarter
I think this is an interesting idea but given the broad range of things we have
in Calcite; a PR could range from linq4j to say the Geode adapter...
If you open https://github.com/apache/calcite/pulls how many you feel confident enough to give a
"merge" (optionally after chanages) or "close PR" decision for it?
I think what makes this project great is that we have a lot of people here with strong views and high standards - this is good in a sense that the best solution is choosen
in most cases.
The presence of the above also puts more weight on committers to accept only
changes which are up to these high standards.
I'm not sure how many of you have merged in a PR from a contributor which
contained serious issues - which have surfaced later and caused issues.
Did you feeled ashamed that you let that patch in - and was not doing your part correctly. Because I did... I know its community effort and everything but afterall it was
me who pushed the merge button...
I had the opportunity to experience a support process built on a similar principle "you just have to carry it" and I have to say that a process like this to work I see the
following options:
* we should have people to ask help from - who actually do respond
** note that in this case the review and the decision to accept the change would *still* stay with the original owner/etc - so it will not mean much improvement beyond
having 1 more people in the chain who is shouting out for others...
* accept that sometimes non-optimal solution will be choosen (which are in most
cases still valuable)
I think in case of a release its more clear what people are signing up for; its
documented/etc.
For reviews its a bit different; with the proposed system:
* what if you don't find 6 PRs you are confident to be able to review in a
quarter?
* there will be 6 people on this mission at the same time - which could further
increase the chance that people would not take risks
cheers,
Zoltan
On 2/7/22 10:56 PM, Stamatis Zampetakis wrote:
Hello,
I think the main problem is still the lack of active committers/reviewers
and not so much the assignment.
Nevertheless, things would be a bit better if we had people assigned to
PRs. This could certainly help at least offload some work from Julian and
possibly sensibilize more people towards the reviewing process.
We could opt for assigning PRs automatically using filename patterns. This
can be done rather easily and it's already done in various projects e.g.,
Hive [1].
What do you think of putting automatic assignment in place for Calcite?
Who is willing to put their name in the list? At this point I am not
expecting that people in the list will review everything they are assigned
on but maybe they can help out by pointing to other people or simply
setting up the expectations about the PR getting reviewed.
Best,
Stamatis
[1]
https://github.com/apache/hive/commit/2bd6a9d63c28e5cb9bcc44115262d565cdc2bb90
On Sat, Feb 5, 2022 at 5:52 PM Jing Zhang <beyond1...@gmail.com> wrote:
Hi, Julian
There is no doubt that you are the most prolific contributors on the
project.
People often hope to hear professional advice from you because you are the
Calcite project authority.
However people may didn't realize that you are suffering from more and more
requests. I want to sincerely apologize because I often disturb you too.
I'm really glad to hear your feelings.
At the same time, I want to thank you because I got many professional
advices from you. The suggestions are very helpful.
Back to this topic, having an efficient mechanism to merge contributors' PR
is very important to the long-term development of open source projects.
I would like to share my thoughts, hope it helps.
1. It might helpful to know which members are proficient in which modules.
For example, introduce each member's familiar module on the website[1].
There may be many requests sent to other members.
2. For some modules, perhaps only very few members are familiar. (For
example, when it comes to modifying the parser grammar, someone may want to
hear from Julian, and when it comes to hints, someone may want to hear from
Danny.) Maybe it's just my bias. But if this is the real situation, is it
possible to develop more than one members on each module?
3. It could be helpful to assign reviewers for a new pull request.
[1] https://calcite.apache.org/community/#project-members
Best,
Jing Zhang
Julian Hyde <jh...@apache.org> 于2022年2月4日周五 02:18写道：
I make many contributions to this project, in the form of code,
answering questions, leading design discussions, and clarifying bugs
and feature requests. I review more changes than any other project
member. My reward is that I am pestered, daily, with people pleading
for me to review their changes.
It's moderately annoying for me - I just delete the emails (because I
have 200 other emails to delete before I can start productive work).
But it's awful for both the contributors and the project.
Getting PRs reviewed is this project's biggest problem, and has been for
years.
Many of you are team leads, engineering managers, directors of
engineering. This is a process problem. Solving problems like this is
what you do. Fix it.
Julian
