Hey Jagat!
Thank you for your feedback - we should definetly need to improve on these
fronts.
I'll get to that when I could - but I'll also answer your questions here as
well.
On 6/19/20 3:16 AM, Jagat Singh wrote:
One thing which needs improvement is updating of Hive Contributors wiki
with whatever process happens on Github and Build server-side.
The current confluence is silent on what to expect when we create a PR as a
contributor, who will review, what will build system do? Where to look for
errors?
definetly - I've added some parts about opening PR but that's not enough.
I think the "who will review" is a sweet spot already....we have do definetly
work on that part.
Based on my first PR experience, do you manually label PRs as test stable,
unstable etc? I am not sure if that can be automated if not done already
along with auto assigning of reviews as you intend to do with this current
proposal.
no; I don't do it manually :D the job is moving those labels around.
Since adding/removing labels needs access to the repo - and ASF doesn't give
this kind of access to non-committers; that have left me to configure my own
user to do this.
I can update a few things based on what I learnt as I recently started
contributing and I feel these all things are missing. But there are many
things for which I don't know the answer yet and will appreciate if someone
experienced update the wiki to add details like above questions.
It would be great if you could help in this - you know; someone new to a
project see problems differently - and may ask about stuff which is just become
like that.
IIRC there was a thread some time ago about that the way we host our hive.apache.org pages have its days numbered - and we should be moving away from it to something more
modern - like hugo (or some other alternative). I'm bringing this up here because moving to something like that will place the site inside the repo itself - that could
enable to review site changes on PRs as well...
I think we could move either parts of the wiki to a '.md' file based world - I
think we could start with the contributors guide.
There could be low hanging benefits of doing this - like asking for adjustments
to the contribution guide withing a patch which changes the way we test stuff.
cheers,
Zoltan
Thanks,
Jagat Singh
On Thu, 18 Jun 2020 at 20:43, Zoltan Haindrich <k...@rxd.hu> wrote:
Hey Panos!
On 6/18/20 11:54 AM, Panos Garefalakis wrote:
My only suggestion would be to make reviewing per package/label instead
of
files. This will make the process a bit more clear.
we could use path globs to select the files - so it could match on
packages as well
I've not really used it
'**/schq/**'
I recently bumped into this GitHub action that lets you automatically
label
PRs based on what paths they modify and could help us towards that goal.
https://github.com/actions/labeler
Sure; we can also have that as well! they may fit for different purposes.
Aactually - based on the "absence" of some labels (eg: metastore) we may
"skip" some tests.
cheers,
Zoltan
Thoughts?
Cheers,
Panagiotis
On Thu, Jun 18, 2020 at 10:42 AM Zoltan Haindrich <k...@rxd.hu> wrote:
Hey all!
I'm happy to see that (I guess) everyone is using the PR based stuff
without issues - there are still some flaky stuff from time-to-time;
but I
feel that patches go in
faster - and I have a feeling we have more reviewes going on as well -
which is awesome!
I've read a bit about github "reviewers" / "assignee" stuff - because it
seemed somewhat confusing...
Basically both of them could be a group of users - the meaning of these
fields should be filled by the community.
I would like to propose to use the "reviewers" to use it as people from
whom reviews might be expected.
And use the assignee field to list those who should approve the change
to
go in (anyone may add asignees/reviewers)
We sometimes forget PRs and they may become "stale" most of them is just
falling thru the cracks...to prevent this the best would be if everyone
would self-assign PRs which
are in his/her area of interest.
There are some times when a give feature needs to change not closely
related parts of the codebase - this is usually fine; but there are
places
which might need "more eyes"
on reviews.
In the past I was sometimes surprised by some interesting changes in say
the thrift api / package.jdo / antlr stuff.
Because the jira title may not suggest what files will be changed - I
wanted to find a way to auto add some kind of notifications to PRs.
Today I've found a neat solution to this [1] - which goes a little bit
beyond what I anticipated - there is a small plugin which could enable
to
auto-add reviewers based on
the changed files (adding a reviewer will also emit an email) - I had to
fix a few small issues with it to ensure that it works/etc [2].
I really like this approach beacuase it could enable to change the
direction of things - and could enable that contributors doesn't
neccessarily need to look for reviewers.
(but this seems more like just sci-fi right now - lets start small and
go
from there...)
I propose to collect some globs and reviewers in a google doc before we
first commit this file into the repo - so that everyone could add things
he/she is interested in.
cheers,
Zoltan
[1]
https://github.com/marketplace/actions/auto-assign-reviewer-by-files
[2] https://github.com/kgyrtkirk/auto-assign-reviewer-by-files
[3]
https://docs.google.com/document/d/11n9acHby31rwVHfRW4zxxYukymHS-tTSYlJEghZwJaY/edit?usp=sharing
