Gerrit Changes and Merging them into master

[Michael S.]

Hio all,
I will ask indirectly how active the project is.

I see in Gerrit many changes who have a code review and are verified. But it takes along time to merge this into release.

1. How is the procedure for doing this? or How long does it take for merge request?

I think think that it would be nice if reviewd/verfied changes are merged faster.

2. How many people have the right to merge them?

[Jens]

Changes can be merged when they have a +2 code review. Currently there are only three https://gwt-review.googlesource.com/q/project:gwt+status:open+label:code-review%253D2

A +2 code review can be done by the Google GWT team and some additional people acting as maintainers for different parts of GWT or generally have enough trust to do so. A list of maintainers (maybe a bit outdated?) can be found here: https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit

Maintainers / Contributors usually do reviews in their free time, so it might take some time to get a +2 and a final commit.

Is there anything specific you want to see merged sooner than later?

-- J.

[Michael S.]

Hi Jens.

thanks for answering. I have not special needing at the moment but I see a list with many commits and CR +1 and thought it would be nice if the list will be empty.
My last change was unmerged for more than a year.

[Michael S.]

It is possible to become a maintainer or what are the criterias to become one?

I like the project and it would be sad if the project will become inactive due to fewer changes.
There are also Java9 depeding issue which will not be reviewed for example.

[Jens]

It is possible to become a maintainer or what are the criterias to become one?

The Steering Committee of GWT decides who becomes a maintainer for a specific component of GWT or a global maintainer. 

You can find a bit more information here: https://groups.google.com/d/msg/google-web-toolkit-contributors/eq0LsmH2blw/WgCuvRlKFRoJ

Basically you can nominate yourself to become a maintainer, but to get accepted you should probably already have contributed and reviewed patches, become more active by answering questions in gwt-user and join discussions in gwt-contrib so you generally proof you are familiar enough with GWT and can handle the responsibility.

 

I like the project and it would be sad if the project will become inactive due to fewer changes.

Fewer changes are actually good these days, because of the transition GWT is in. Currently contributors are choosing GWT modules and rewrite them to make them J2CL / GWT 3 compatible while maintaining compatibility to GWT 2.x as much as possible. This work is done mostly on Github so you can't see it by looking at contributions in Gerrit. For example there is already a gwt-http project on Github which provides the HTTP GWT module and should be compatible to GWT 2.x and GWT 3 / J2CL: https://github.com/gwtproject/gwt-http

Because of this transition, adding new features to GWT 2.x is unlikely because it would further complicate such rewrites. Contributing bug fixes to GWT 2.x is fine of course. However GWT is relatively stable and urgent bug fixes are rare. So you might indeed get the impression GWT is inactive. However that is not really true.

 

There are also Java9 depeding issue which will not be reviewed for example.

Yeah I agree, Java9 support, including new API emulations, should find its way into GWT sooner than later. GWT usually has to wait for a good Eclipse JDT release as GWT uses it to parse and compile GWT sources. There have been some updates recently, but I don't know if anyone at Google is actively working on updating the GWT compiler to support new Java 9 syntax (e.g. private methods in interfaces).

But if you have free time, you can always start working on API emulations even though you can not really test them using GWTTestCase. But you can still push them to Gerrit and mark them as "Work in progress" until GWT compiler and CI Server are ready for Java 9. But if you really want to work on API emulation then you MUST NOT look at source code of Oracle JDK or OpenJDK while implementing these APIs to make sure you are not coping them intentionally. Otherwise we can not accept such contributions.

-- J.

[Roberto Lublinerman]

There are also Java9 depeding issue which will not be reviewed for example.

Yeah I agree, Java9 support, including new API emulations, should find its way into GWT sooner than later. GWT usually has to wait for a good Eclipse JDT release as GWT uses it to parse and compile GWT sources. There have been some updates recently, but I don't know if anyone at Google is actively working on updating the GWT compiler to support new Java 9 syntax (e.g. private methods in interfaces).

FYI, the new language features introduced in Java 9 (private interface methods and a small improvement in try with resources) are already committed to HEAD (https://gwt.googlesource.com/gwt/+/6407ba9f1e5c02412035689653484c86f9321992).

[Michael S.]

thanks for answering

[Jens]

FYI, the new language features introduced in Java 9 (private interface methods and a small improvement in try with resources) are already committed to HEAD (https://gwt.googlesource.com/gwt/+/6407ba9f1e5c02412035689653484c86f9321992).

Oh nice. Didn't noticed it. If we avoid private interface methods and the try-with-resource enhancements, adding Java9 API emulation should be compatible with Java8 VM ?

-- J.