|Re: [jgit-dev] GerritForge's JGit E2E tests with Gerrit in 2022|
|Hi Matthias, thanks for sharing your feedback.|
See my comments below.
Sure, all proposals for the JGit project and associated discussion will happen here.
The  above is a GerritForge’s initiative announcement, like the JGit E2E tests with Gerrit we introduced a long ago and published in the past .
True, I agree with your analysis. However, some of the reviewers and committers who wrote a large part of the code-base are inactive and won't be back to help us out.
The only solution is to increase the volume of reviews and get more changes merged. We do need more people with more knowledge and experience with the code.
Currently, I can only observe the numbers that show a yearly decline in the number of merged changes. Also, the number of active committers is in evident decline.
GerritForge wants to help here, provide more testing, more input, more reviews, more ideas, more changes, and make things better for everyone.
The focus is on making JGit + Gerrit tests work E2E, not creating any fork.
The workflow of using a “runway” of changes all cherry-picked (or rebased) and getting extra integration tests *before* merging them is pretty common.
Also, Zuul implements *that* workflow (see  for an overview of how the process works).
I fully agree with all of the above: I believe it deserves a separate discussion thread because of its importance and increased visibility and discoverability. This topic is about testing JGit and Gerrit together on master branch.
Yes, I recall the discussion, and there is a global consensus on that.
I believe that having E2E tests of JGit + Gerrit executed on the “changes on the runway” to be merged would also help the Gerrit side update the submodule pointer to JGit master soon as possible.
P.S. Currently, JGit master and Gerrit master don’t even build together until Gerrit change  is merged.
You do need a "stream of changes together" (to highlight that the focus is NOT the branch) because when you run the integration tests, you need to see and check things working together, not in isolation.
Let me give you a simple example:
Verifying all individual changes in isolations won't tell you if they work together.
With the "stream of changes", you will do instead:
The above example is very simplistic. The problem is a lot more complex than that; however, it shows that creating a "stream of changes" for validation is key when you want to integrate and validate multiple components.
There is also an issue with execution times and tradeoffs with the speed of validating incoming changes.
Running E2E tests takes a long time (hours) and is very expensive (hundreds of $ of infrastructure time): you want to limit that to ONLY those changes that:
- Have passed the normal verification process (e.g. Eclipse's CI)
- Have been reviewed and have no vetos from being approved
The two aspects depicted above represent the reason why the trigger for running the E2E tests *cannot* be applied for all open changes targeting master.
Sure, that is crystal clear. Having more E2E tests of JGit with Gerrit will increase the confidence in merging changes that have been stuck in review for a very long time.
We address the confidence in merging changes where current active reviewers and commits have a lack of knowledge of the underlying code.
IMHO projects should not be stuck because the original author of the code isn’t around anymore to maintain it.
Open-Source is great because allows the code initially written by one author to be reviewed, modified, extended by the whole community.
The lack of knowledge should never impede contributions, reviews or approvals.
If I am not confident about one change, I’ll write more tests to verify its correctness.
If I don’t understand some parts of the source code, I’ll spend more time reading it more carefully.
Our efforts in improving the E2E testing of JGit with Gerrit is directed at *improving* the confidence of current and new reviewers and contributors.
I hope that the JGit community would appreciate our initiative and help with our endeavour.
The tests are E2E with a real Gerrit setup, including:
- LDAP authentication
- Shared filesystem on NFS
- multiple Gerrit primaries
You know better than me that only executing in a production environment we could discover some very nasty JGit bugs, and we (actually you) managed to fix them before the Gerrit release.
We want to facilitate and help with the process and adding more testing.
Sure, that is something we should do regardless.
I’d be happy to help with that, as I already do it for the Gerrit project.
Do you know where the JGit pipeline is stored and maintained?
Sounds good, looking forward to it !
Thanks again for taking the time to provide your valuable feedback and reading about initiative.
Back to the top