Bug P3
Status Update
No update yet.
Comments
ek...@google.com
> Can we enforce javadoc on (new) public classes/methods by ErrorProne?
The bug patterns that are supported by ErrorProne are described at [1]. There seems to be none to enforce javadoc on (new) public classes/methods.
[1]https://errorprone.info/bugpatterns
The bug patterns that are supported by ErrorProne are described at [1]. There seems to be none to enforce javadoc on (new) public classes/methods.
[1]
ek...@google.com
ek...@google.com
Jgit has a way to enforce this:
- Eclipse has a setting to enforce this, and the CI uses the Eclipse Java compiler which respects the Eclipse setting.
Can we configure this compiler for the Gerrit Bazel build too.
Likely this cannot differentiate between newly added and previously existing code (should be double-checked).
- Eclipse has a setting to enforce this, and the CI uses the Eclipse Java compiler which respects the Eclipse setting.
Can we configure this compiler for the Gerrit Bazel build too.
Likely this cannot differentiate between newly added and previously existing code (should be double-checked).
ek...@google.com
[Empty comment from Monorail migration]
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://gerrit.googlesource.com/gerrit.git/+/6f3879d27b074cea4b6a6f181637c1bf5710cc5f
commit 6f3879d27b074cea4b6a6f181637c1bf5710cc5f
Author: Edwin Kempin <ekempin@google.com>
Date: Wed Nov 20 08:12:59 2019
Document that public classes/methods should have Javadoc
Often public methods/classes in the Gerrit source code are not
sufficiently documented, making it hard for readers to understand the
purpose of methods/classes and understand how classes work together.
Bug:https://crbug.com/gerrit/11954
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I055da6f5362a42466c34668d96f4bd050f44fe2e
[modify]https://gerrit.googlesource.com/gerrit.git/+/6f3879d27b074cea4b6a6f181637c1bf5710cc5f/Documentation/dev-crafting-changes.txt
commit 6f3879d27b074cea4b6a6f181637c1bf5710cc5f
Author: Edwin Kempin <ekempin@google.com>
Date: Wed Nov 20 08:12:59 2019
Document that public classes/methods should have Javadoc
Often public methods/classes in the Gerrit source code are not
sufficiently documented, making it hard for readers to understand the
purpose of methods/classes and understand how classes work together.
Bug:
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I055da6f5362a42466c34668d96f4bd050f44fe2e
[modify]
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://gerrit.googlesource.com/gerrit.git/+/6f3879d27b074cea4b6a6f181637c1bf5710cc5f
commit 6f3879d27b074cea4b6a6f181637c1bf5710cc5f
Author: Edwin Kempin <ekempin@google.com>
Date: Wed Nov 20 08:12:59 2019
Document that public classes/methods should have Javadoc
Often public methods/classes in the Gerrit source code are not
sufficiently documented, making it hard for readers to understand the
purpose of methods/classes and understand how classes work together.
Bug:https://crbug.com/gerrit/11954
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I055da6f5362a42466c34668d96f4bd050f44fe2e
[modify]https://gerrit.googlesource.com/gerrit.git/+/6f3879d27b074cea4b6a6f181637c1bf5710cc5f/Documentation/dev-crafting-changes.txt
commit 6f3879d27b074cea4b6a6f181637c1bf5710cc5f
Author: Edwin Kempin <ekempin@google.com>
Date: Wed Nov 20 08:12:59 2019
Document that public classes/methods should have Javadoc
Often public methods/classes in the Gerrit source code are not
sufficiently documented, making it hard for readers to understand the
purpose of methods/classes and understand how classes work together.
Bug:
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I055da6f5362a42466c34668d96f4bd050f44fe2e
[modify]
ma...@gmail.com
[ms] at least the API classes (among all public ones) could be treated first.
So first to identify which packages hence classes are public API ones.
Then document those, thus make those more discussed as review comments.
[ms] Once passed the started documentation step, goal would be to automate the checking of such javadoc.
How about starting with a scripted diff that could focus on if a change touches the previously listed API class files.
(Just an idea; the spirit matters more here.)
So first to identify which packages hence classes are public API ones.
Then document those, thus make those more discussed as review comments.
[ms] Once passed the started documentation step, goal would be to automate the checking of such javadoc.
How about starting with a scripted diff that could focus on if a change touches the previously listed API class files.
(Just an idea; the spirit matters more here.)
ek...@google.com
[Empty comment from Monorail migration]
ek...@google.com
[Empty comment from Monorail migration]
is...@google.com
Edits were made to reflect the following in Monorail: auto-CCs.
Description
What is the issue that should be resolved?
Often public methods/classes in the Gerrit source code are not sufficiently documented.
How does it impact your experience with Gerrit?
This often makes it hard for readers to understand the purpose of methods/classes and understand how classes work together.
Please include ideas on how the issue could be addressed below:
Can we enforce javadoc on (new) public classes/methods by ErrorProne?