Hi Nasser,Thanks for the reply, answers inline.
On Jan 18, 2022, at 1:06 PM, Luca Milanesio <luca.milanesio@xxxxxxxxx> wrote:
Hi Thomas,
Thanks for the feedback, see my comments inline.
On 18 Jan 2022, at 19:01, Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
On 18.01.22 16:37 , Luca Milanesio wrote:
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/
Somehow it seems to me that this proposed dev branch would become a
de-facto fork. The writeup mentions this danger already.
That’s exactly what we are NOT aiming to: the ‘dev’ branch should be more a “fast lane” for faster verifications and merge, not a slowdown for incoming changes.
Also, none of the changes on the ‘dev’ branch will be merged into ‘master’ until it will get +2 by any maintainers, so it won’t be a risk for the JGit project’s master branch.
Should any of the changes on the ‘dev’ branch be vetoed, then we’ll revert it on the ‘dev’ branch also, for preventing the two branches to diverge.
As soon as you create a branch like this, you’re setting up for a fork. Don’t have the branch and you won’t end up forking. As noted below, this dev branch doesn’t solve the problems you’re trying to address. Do you think it solves something that you can’t do with open changes on master?
If you replace ‘dev’ with ‘fetch a series of open changes on master’, then it is exactly what we already do with verification of chained changes on the Gerrit project.
The proposal
also does not address the main bottleneck: too few active reviewers
and committers in JGit.
Correct, not directly. The *hope* is that the JGit community will see the growing contributions and competence shown by the new contributors and, eventually, decide to promote more contributors as new maintainers.
The current pace of contributions and reviews, from what we see on our changes, is too slow, which would bring the potential “promotion to maintainers” to many months (or years?) in the future.
I don’t think all JGit changes suffer from slow reviews and the pace of contributions is up to the contributors. This also misses that future JGit committers (maintainers) can also speed their path to promotion through reviewing others’ changes. That would seem to provide the most value because it directly addresses the concern of review not happening fast enough. If you care about that problem generally for the JGit project, this is an obvious way to contribute.
Sure, we need more reviewers and maintainers, both are needed and required.
I think a better way to speed up things would be to on-board new
committers. (And officially retire inactive ones.) If things don't go
fast enough for GerritForge, see that it has active committers in JGit,
and develop on master.
So far, it did not go fast enough :-(
What’s GerritForge’s plan for getting more contributors as JGit committers then? Sounds like the prerequisites would be 1) Contribute more JGit changes that get merged and 2) Help get other JGit changes merged through good reviews.
See [2].
As for "Gerrit edge releases": I think you can do that already. Gerrit
builds JGit in tree, as a submodule, right? So just bump the submodule
pointer to the commit hash you want and build.
Sure, that’s a good idea regardless: as I mentioned, testing E2E with Gerrit is *always a good thing to do*.
I’m all for more E2E testing with Gerrit. That part of this proposal is awesome (and is very similar to ideas Martin and I have discussed in the past). I’m strongly against (and this needs discussion on the Gerrit list) any workflow that allows for a path where Gerrit uses a ‘dev’ version of JGit (purposefully or accidentally).
In the workflow at [3], the Gerrit changes does not get merged but is simply a *verification point* that the JGit change doesn’t break Gerrit E2E.
Thanks for your input, appreciated it.
Luca.
|
