Hi,
Every once in a while a change is submitted that makes the project stop building in Eclipse (see [1] for one example, but there are many others). That defeats the usual goal of a clean, bisectable history and a "master" branch that is always in a releasable state.
Usually this is my fault, since I'm one of the few maintainers that doesn't use Eclipse as part of my everyday workflow. Sorry about that.
There were some nice suggestions In [1] for improving matters:
1. Improving CI and commandline-triggered tests to catch this kind of error, for example by changing the Maven build to use ecj configured with the same settings as the IDE project.
2. Relaxing project settings to treat anything that is not enforced by the build as a warning instead of an error.
3. Not marking a change Verified+1 until someone has run a build in Eclipse.
One kind of error Eclipse diagnoses is ABI and API breakage (typically missing "@since" annotations, but sometimes more severe). These require a baseline so I suspect they'd be hard to set up in (1). They are important enough that I don't think they warrant (2).
That leaves (3). Should we set up a separate label (e.g. "Eclipse-Verified") for manual verification in Eclipse? Alternatively, we could document in the contributor guide that maintainers should not vote Code-Review+2 until a change has been tested in Eclipse.
If I've guessed wrong and (1) is actually easy to set up, that would be even better.
Thoughts of all kinds welcome.
Thanks,
Jonathan
