Long term concerns

[rluble]

The J2CL project has been relying on JDT as its frontend for Java since its inception and has served us well. Since J2CL moved with the Java updates cadence at Google, we always found blockers to be resolved by the time J2CL needed to update to a more current JDT version. But it looks like we are going to start upgrading at a higher cadence and that raises the concern on how to handle blockers.

For example, in our latest attempt to update to the current version we found a couple of issues that are blockers for us (issues #2941and #2949). I was wondering if it is realistic to assume those kinds of issues will be fixed relatively quickly or should we expect longer delays with the current founding level of the project.

Roberto Lublinerman on behalf of the J2CL team.

[iloveeclipse]

we are going to start upgrading at a higher cadence and that raises the concern on how to handle blockers.

For blockers I personally would try to provide:

1. Reproducible test case
2. PR with a patch
3. or at least bisect to a commit that broke something

With this approach my company had good experience contributing to open source projects.

I was wondering if it is realistic to assume those kinds of issues will be fixed relatively quickly or should we expect longer delays with the current founding level of the project.

It depends.

In case the problem is a blocker for JDT or platform you could expect a fix in a work week or faster.

Anything else is, as you've mentioned, depends on the current resources available, and there aren't many. So a proactive contribution to this project is the best way you could assume quick fixes.

[stephan-herrmann]

For blockers I personally would try to provide:

1. Reproducible test case

Let me expand a bit on this:

For compiler bugs a complete source example goes a long way. If we can paste the code to a file without any further tweaks, invoke the compiler and see it accepted/rejected incorrectly, then we know what to look at.

One of your issues mentioned unexpected bindings, so we are in white-box land. Here an actual junit test would actually increase your chances that the issue is being looked at, because otherwise we'd need to figure out the exact call sequence that will reproduce the issue. By that time another bug report may have already diverted our attention.

In a way it's a game: if your bug report scores high in severity and very low in effort for reproducing, than it will beat other reports with not so good scores :)

But of course: nothing beats a quality patch. And once we see you're trying your best to fix the issue, then will be glad to help you completing the task.

[stephan-herrmann]

But it looks like we are going to start upgrading at a higher cadence and that raises the concern on how to handle blockers.

A higher cadence on your side could actually help: when you report a "fresh" regression, then it will be easier to find the bad change, and memory of that change is still fresh. The "ideal" bug report is filed against an I-build or milestone, at which point it is most valuable feedback.