Dear Gerrit and JGit developers’ community,
I would like to share with you the GerritForge’s plans for adding more E2E tests to JGit changes in 2022 [1].
Opinions, suggestions, objects, any sort of feedback is more than welcome :-)
Luca.
[1] https://gitenterprise.me/2022/01/18/new-year-new-jgit-contributions-coming/
I would prefer to see your proposals posted on this list instead of your website since it would be easier
to respond and follow the conversation.
I think the main reason why some contributions to jgit stay in review for a long time is a lack of active reviewers.
This won't improve by adding yet another branch in a fork. I think the existing jgit master branch is the
development branch.
We spent quite some time in the past on reviewing and testing patches for older jgit releases and
merging them up to master since Gerrit was reluctant to update older Gerrit maintenance branches to
use the latest JGit maintenance branch. This added overhead and ate some of the limited capacity we have.
Hence I propose we stop this to better use our limited resources by
- limiting development of new features to the master branch
- limiting maintenance of releases to the latest release (currently 6.0)
- maybe as an exception to this rule allow fixes for the last minor release of the last major release (currently 5.13).
Some users asked for this since they still depend on Java 8 which is no longer supported since jgit 6.0 - declaring EOL on all older releases
Gerrit actively maintains its last 3 releases (currently 3.3, 3.4, 3.5). Last week the Gerrit Engineering Steering Committee
defined a new policy for updating JGit [1] on Gerrit maintenance branches supporting this proposal to reduce the number
of active JGit maintenance branches.
I appreciate the proposal to run more tests like Gerrit integration tests against open jgit changes.
I don't understand why another branch is needed for implementing that. Instead these tests should be run
on the open changes. Running more tests can help to find more problems and prevent regressions but
doesn't fix the problem that we need more active reviewers.
The JGit CI [2] uses Eclipse CBI [3] to run builds and tests on Jenkins running in Kubernetes.
I guess the proposed tests could also be run there. If we need more resources there we can add some more.
As proposed by David Ostrovsky we should also aim at verifying the bazel build and tests in JGit CI.
Unfortunately it can't fully replace the Maven build since there is no support in bazel for building OSGi bundles,
Eclipse features and p2 repository which is required for installing it in Eclipse IDE.
If someone has time to help improving JGit CI we'd appreciate that. Thomas Wolf implemented a pipeline
library for the egit builds [4], but we didn't find time yet to do something similar for the jgit builds.
I am looking forward to your and your colleagues' contributions. If they are coming as you said we may have
some new jgit committers soon. If possible please also plan time to help with reviewing changes from other
contributors.
-Matthias
